SOC 2 Processing Integrity Criteria Explained (2026 Guide)

Processing Integrity is the optional SOC 2 category that tests whether your system processes data completely, validly, accurately, on time and with authorization. It has five criteria, PI1.1 to PI1.5, which follow data from definition through inputs, processing, outputs and storage. Add it when customers rely on your outputs being right, not only protected.

Security’s Common Criteria (CC1 to CC9) apply to every SOC 2 report, so Processing Integrity adds its five criteria on top of them. This page takes each one in turn: what it asks, the control and evidence we map to it, what a Type 2 sample looks like, and where teams usually fall short. For choosing among all five categories, see the Trust Services Criteria guide.

What does Processing Integrity cover?

The AICPA defines the category as system processing that is “complete, valid, accurate, timely, and authorized to meet the entity’s objectives” (2017 Trust Services Criteria, revised points of focus 2022). Those five words are the attributes an auditor tests. They are not the five criteria. The criteria are PI1.1 to PI1.5.

The criteria text leans mostly on “completely, accurately, and timely.” Validity and authorization show up in the controls you design to meet them. In our controls library, completeness sits mainly with job monitoring and reconciliation, validity with input checks, accuracy with tested processing logic and reconciled outputs, timeliness with late-job alerts, and authorization with access limits on stored records plus change approval under CC8.1. That mapping is ours, not the AICPA’s.

Check numbering when you read older write-ups. A 2017 Linford & Company post lists six criteria, PI1.1 to PI1.6, with storage as PI1.4 and output as PI1.5. In the current criteria there are five, with output at PI1.4 and storage at PI1.5.

What does an auditor test under PI1.1 to PI1.5?

Each criterion maps to a control, a cadence and Type 2 evidence. PI1.1 needs written specifications, PI1.2 input validation, PI1.3 job monitoring and tested logic changes, PI1.4 reconciled outputs, and PI1.5 protected, audit-trailed storage.

The controls below are PRC-01 to PRC-06, six of the 82 controls in our library. A Type 1 report asks only whether they are designed and in place on one date. A Type 2 report tests whether they operated through the period, which is what the last column shows. The auditor chooses the sample, and the AICPA sets no minimum sample size; SOC 2 sample size covers how auditors decide.

PI1.1: are processing objectives and data definitions written down?

PI1.1 asks the entity to obtain or generate, use and communicate quality information about its processing objectives, including definitions of the data it processes and its product and service specifications. PRC-01 turns that into a document per in-scope workflow: the inputs it accepts, what it does to them, the outputs it produces, and the accuracy and timing you promise customers.

Auditors ask for the specification or data dictionary and the customer-facing text that states the commitment. In a Type 2 period they check that the specification changed when the processing changed. The common gap is logic that lives only in code and in engineers’ heads, which leaves the auditor nothing to test outputs against. Every later criterion is measured against this document.

PI1.2: are inputs checked before they enter processing?

PI1.2 covers policies and procedures over system inputs, including completeness and accuracy. PRC-02 validates inputs on the server for type, format, range and required fields, rejects or holds bad records, and logs each rejection so someone can correct it.

The evidence is the validation rules in code or configuration, plus rejected-input logs or an error queue showing how each record was resolved. A Type 2 sample reads those logs across the period and follows rejected records to a correction or a return to the sender. The usual gap is validation that runs only in the browser, so API callers can submit records that skip it.

PI1.3: is processing monitored, and are logic changes tested?

PI1.3 covers policies and procedures over system processing. Two controls carry it. PRC-03 monitors jobs for failures, delays and incomplete runs, alerts an owner, and records how each exception was fixed or the data reprocessed. PRC-04 tests every change to processing logic, such as calculations and transformations, against expected results before release, hotfixes included.

Evidence is the monitoring dashboard and alert settings, exception tickets showing cause and resolution, test cases with expected results, and release records showing they passed. The sample is every exception raised in the period with its resolution, and the passing tests for each logic change released. Change approval and testing also fall under CC8.1; PRC-04 is the processing-logic version of that testing. The gaps our library flags are jobs that retry silently or drop records, with no way to show every input was processed, and hotfixes that skip the test suite.

PI1.4: are outputs complete, accurate, on time and sent to the right place?

PI1.4 covers making output available or delivering it completely, accurately and timely in accordance with specifications. PRC-05 reconciles outputs to inputs using record counts or control totals and delivers outputs only to intended recipients through approved channels.

The evidence is the reconciliation report, with any differences and how they were resolved, and delivery settings showing recipients and access restrictions. A Type 2 auditor wants a reconciliation for each run or batch they sample. The common gap is output that is checked for format but never reconciled to inputs, so missing records go unnoticed.

PI1.5: are inputs, in-flight items and outputs stored intact?

PI1.5 covers storing inputs, items in processing and outputs completely, accurately and timely in accordance with system specifications. PRC-06 protects those records from unauthorized change, keeps an audit trail of changes, and retains them as long as your specifications require.

Evidence is the audit-trail or change-history settings, access settings limiting who can modify stored processing data, and retention settings. The sample is audit-trail entries across the period showing changes were captured and traceable to a person or process. The gap is records that can be edited with no history, so nobody can show that stored outputs still match what was originally produced. For the exact artifacts to gather, use the evidence request list; the full set sits in the controls library.

What does a Processing Integrity exception look like in a billing job?

Take a usage-based billing platform (an illustration, not a client). Each night a job rates usage events into invoice lines, and the specification says rated lines must be ready by 06:00 UTC. The control is that every run is reconciled and every exception resolved before invoices release. One night runs like this:

1. Specification (PI1.1). The data dictionary says every usage event carries an account ID, timestamp and quantity, and names the rating rule per plan.
2. Input (PI1.2). The job receives 48,210 events. Server-side validation rejects 33 for a missing account ID and sends them to the rejection queue, which opens a ticket for billing operations.
3. Processing (PI1.3). The job rates the other 48,177 events and finishes before 06:00. Monitoring stays quiet; the only alert is the rejection ticket.
4. Output (PI1.4). The reconciliation compares 48,210 received with 48,177 rated plus 33 rejected, and the quantity control total matches. Invoices are held.
5. Resolution. Billing operations traces the 33 events to an upstream connector change that dropped the account ID field. The mapping is fixed, the events are reprocessed the next morning, and a second reconciliation shows 48,210 rated and none rejected. The ticket links both reconciliations and approves release.
6. Storage (PI1.5). The audit trail shows the reprocessing under a named service account, and the original rejected records are retained.

A Type 2 auditor does not retest this night. They take the population of nightly runs for the period and sample from it. For each sampled run they ask for the reconciliation, and for any run with rejections, the ticket. A run where records disappeared and no ticket exists is the exception that appears in the report. If the team hotfixed the rating rule in month four, the change population is sampled too, and PRC-04 evidence is the test result that predates the release.

When is Processing Integrity worth adding?

Add it when customers rely on your outputs and can ask, “How do you know these numbers are right and complete?” That describes payments, billing, payroll, claims, tax and calculation products. Skip it, for now, when your product stores or relays data without transforming it in ways customers depend on, and your buyers only ask for a baseline SOC 2.

Few reports include it. In CBIZ’s 2024 benchmark of 73 SOC 2 reports, all covered Security, 75.3% Availability, 64.4% Confidentiality, 13.7% Processing Integrity and 6.8% Privacy (CBIZ 2024 SOC Benchmarking Report). That is one firm’s sample, so read it as an order of magnitude. It also suggests that a buyer who asks for Processing Integrity usually has a specific reason.

Each criterion adds controls to run and evidence to keep for the whole examination period, and the category can be scoped to the system that produces the output rather than the whole company. For price effects, see SOC 2 audit cost. To see how added categories change the examination, read SOC 2 requirements.

Once Processing Integrity is in scope, auditor fit matters more. A firm that mostly does Security-only startup reports may be less practiced at testing application logic. Ask how they would sample transactions, trace a failed job, inspect validation rules, and confirm that a fix was tested before release. Browse the SOC 2 auditor directory to compare firms, or run the readiness assessment first to see where your processing controls stand.