SOC 2 Processing Integrity criteria (PI1.1–PI1.5)

By Sam Rivera, Founder, SentinelPanda · August 10, 2026 · 2 min read · SOC 2

Processing Integrity is not "our software has no bugs". It is a claim about controls over inputs, processing, and outputs — and most companies should not select it.

The five criteria

PI1.1 — you obtain or generate and communicate quality information about processing objectives: what the system is supposed to do with data, defined well enough to test against.
PI1.2 — inputs are complete, accurate, and timely, and processed only if authorised.
PI1.3 — processing itself is complete, accurate, timely, and authorised.
PI1.4 — outputs are complete, accurate, timely, and distributed according to specification.
PI1.5 — inputs, items in process, and outputs are stored completely, accurately, and timely.

The misunderstanding

Teams read "Processing Integrity" as a promise the product works correctly, panic, and either decline the category or commit to something unbounded. Neither is right.

The category is scoped to the processing objectives you state. If your system description says the platform ingests transaction files, applies a documented fee calculation, and produces a settlement report, that is what gets tested — completeness of ingestion, accuracy of the calculation, timeliness and correct distribution of the report. It is not an assertion that no bug exists anywhere in your codebase.

Framed that way it is testable: reconciliation controls, input validation with rejection handling, exception queues that someone actually works, output checksums or record counts, and evidence that discrepancies were investigated.

When it is worth selecting

When you compute something on a customer's behalf that they cannot easily verify and would be materially harmed by getting wrong — payments and settlement, payroll, billing and metering, tax calculation, clinical or financial reporting, analytics customers make decisions on.

For most B2B SaaS — collaboration tools, CRMs, GRC platforms — it adds cost without answering a question anyone asked. Security and Availability carry those procurement conversations. Processing Integrity is the least-selected of the five categories for good reason, and adding it speculatively is a common way to inflate an audit.

What auditors ask for

Documented processing objectives — the definitions PI1.1 requires, which many teams have never written down.
Input validation evidence: what is rejected, where rejects go, who resolves them.
Reconciliation between input and output volumes or values, performed on a cadence, with discrepancies followed up.
Error and exception handling that shows resolution, not just detection — an alert nobody actions is not a control.
Change management over the processing logic specifically, tying back to the Common Criteria.

SOC 2 Trust Services Criteria SOC 2 common criteria explained SOC 2 change management