SOC 220 April 2026 7 min read

SOC 2 Processing Integrity: What PI1 Criteria Require

SOC 2 Processing Integrity (PI1.1–PI1.5) explained — who needs it, what the five criteria require, and the evidence auditors collect for payment and data processing companies.

Key Takeaways

Processing Integrity has five criteria (PI1.1–PI1.5) covering complete, valid, accurate, timely, and authorized processing.
This TSC is most relevant for payment processors, ETL pipelines, financial reporting systems, and data transformation platforms.
Most pure SaaS application companies do not need Processing Integrity — delegation to Stripe covers payment processing.
PI1.2 (input completeness/accuracy) and PI1.3 (processing accuracy) require code-level data validation controls audited via PR review.
Reconciliation reports and error logging are the primary operational evidence for Processing Integrity.

In this guide

Who Needs Processing Integrity
PI1.1 and PI1.2: Inputs and Processing Objectives
PI1.3 and PI1.4: Output Completeness and Delivery
PI1.5: Stored Data Completeness
Evidence Auditors Request for PI
Processing Integrity vs Availability: The Difference

Who Needs Processing Integrity

The Processing Integrity TSC addresses whether your system processes data completely, accurately, validly, in a timely manner, and only as authorized. It is relevant when incorrect or incomplete processing would directly harm customers or violate contractual commitments about data accuracy.

Primary use cases: payment processors where a missed transaction or duplicate charge has direct financial consequences; ETL pipeline companies where incorrect data transformation produces inaccurate analytics for customers; financial reporting platforms where calculation errors could cause compliance violations; and data synchronization services where data loss between systems is a critical failure mode.

Most pure SaaS application companies using Stripe for payment processing do not need to add Processing Integrity to scope. Stripe's SOC 2 report covers the payment processing controls. If your application simply calls Stripe's API and records the result, you are not "processing" payments in the sense PI1 evaluates. If you build custom billing logic, recurring payment orchestration, or financial calculations on top of a payment provider, you may have PI1 exposure.

PI1.1 and PI1.2: Inputs and Processing Objectives

PI1.1 requires that the entity defines processing specifications and objectives. Evidence: processing specification documentation describing what the system is designed to do, including data formats, processing rules, and expected outputs; SLA documentation covering processing timeliness commitments; architecture documentation showing data flow from input to output.

PI1.2 requires that inputs are complete and accurate before processing. Evidence: input validation code (reviewed via PR records); error handling for invalid inputs (test records showing invalid inputs are rejected); data completeness checks at ingestion points; rejection logs showing invalid inputs were caught and not processed; reconciliation records comparing input record counts to processed record counts.

PI1.3 and PI1.4: Output Completeness and Delivery

PI1.3 requires that system processing is complete, accurate, and timely. Evidence: processing output reconciliation reports (input count = output count with documented variance handling); error rate monitoring dashboards with alerting on threshold exceedances; audit trails showing processing steps and timestamps; sampling records from auditor re-performance of processing logic.

PI1.4 requires that outputs are complete and delivered to authorized recipients. Evidence: output delivery confirmation logs; access controls on output data ensuring only authorized parties receive outputs; delivery SLA tracking and alerting; records of output error notifications and remediation when delivery failed.

PI1.5: Stored Data Completeness

PI1.5 requires that stored data remains complete and accurate and is available for retrieval as committed. This criterion addresses data integrity at rest — ensuring that stored records haven't been corrupted, truncated, or lost since they were written.

Evidence: database integrity check processes (automated consistency checks, foreign key constraint reporting); backup validation records showing backup data can be successfully restored and is complete; data checksum or hash verification processes for critical data sets; monitoring alerts for database replication lag or consistency failures.

PI1.5 is frequently evidenced by backup test records (which are also A1.3 evidence). A company with a robust backup and restoration testing program has most of the PI1.5 evidence already available.

Evidence Auditors Request for PI

Input validation: code review records showing validation logic was reviewed; test records for input validation rules; rejection logs showing invalid inputs were caught. Processing accuracy: reconciliation reports comparing input to output counts; error monitoring dashboards; incident records for any processing errors during the observation period.

Output delivery: delivery confirmation logs for critical outputs; access control configuration for output data; any delivery failure notifications and how they were resolved. Data integrity: database consistency check results; backup restoration test records; data integrity monitoring alert configurations.

Auditors frequently request a reconciliation report covering a specific processing run and then independently verify the counts or calculations using their own analysis. This re-performance testing is a distinguishing feature of PI1 audits — be prepared to explain your processing logic to a CPA who may not be deeply technical.

Processing Integrity vs Availability: The Difference

Processing Integrity and Availability address different dimensions of system reliability. Availability asks: "Was the system operational when it was supposed to be?" Processing Integrity asks: "When the system ran, did it produce correct results?" A system can be highly available (99.99% uptime) but have processing integrity failures (incorrect calculations, data loss). A system can have perfect processing integrity but poor availability.

Some companies add both TSC. Payment processors and financial data platforms often include both because their customers care about both uptime and calculation accuracy. However, most SaaS companies choose one or the other based on their primary service commitment.

A key distinction: Availability failures are typically visible to customers immediately (the app is down). Processing Integrity failures may be invisible for days or weeks until a reconciliation reveals a discrepancy. This makes monitoring and detective controls particularly important for PI1 — you need automated reconciliation and error detection, not just reactive incident response.

Frequently Asked Questions

Does using Stripe eliminate the need for Processing Integrity TSC?

For most companies, yes. If your payment processing is fully delegated to Stripe with no custom billing logic, Stripe's SOC 2 report covers the payment processing controls. You reference Stripe as a subservice organization in your system description. If you build custom logic on top of Stripe — custom subscription management, custom proration calculations, complex multi-currency billing — you may have PI1 exposure for that custom logic.

What is a reconciliation report for SOC 2 purposes?

A reconciliation report is a document comparing input counts, amounts, or records to output counts, amounts, or records to verify that processing was complete and accurate. For a payment processor, this might compare the count of payment instructions received to the count successfully processed, with a zero or explained variance. For an ETL pipeline, it might compare source record counts to destination record counts. The reconciliation demonstrates that no records were lost or added during processing.

How does PI1 interact with CC8 (Change Management)?

CC8 and PI1 both care about code changes to processing logic. A change to a calculation algorithm must go through the CC8 change management process (PR review, testing, approval) and the result must be reconciled to verify the new logic produces correct outputs (PI1.3). Auditors sometimes test both criteria using the same evidence: a PR record showing a processing logic change was reviewed, and a reconciliation report showing the change produced correct results.

Is there a minimum error rate for Processing Integrity?

The AICPA doesn't specify error rate thresholds. Auditors evaluate whether processing is "substantially complete and accurate" — some level of errors is expected and acceptable as long as they are detected, logged, and remediated promptly. What's not acceptable is systematic errors that aren't detected, or errors that aren't reported to affected customers. Your error handling procedure and the evidence that errors were caught and corrected matter more than the absolute error rate.

Can we add Processing Integrity only for part of our product?

SOC 2 scope is defined at the system level, not the feature level. However, you can define your "system" narrowly to include only the components that perform processing operations — the payment processing service, for example — while excluding the broader application. This is a more complex scope definition that requires careful system description writing, but it limits PI1 evidence requirements to the relevant components.