SOC 2 processing integrity criteria

The SOC 2 processing integrity criteria, SOC 2 PI1.1 to PI1.5, ask a service that processes data for customers to define what correct processing means and then show that inputs, processing, outputs and stored data are complete, accurate, timely and authorised. Include the category only when customers rely on the results your system produces.

The requirement in plain English

Processing Integrity is one of the four optional categories. It fits services whose job is to calculate, transform or move data: payroll, payments, billing, insurance claims, data pipelines.

Define correct (SOC 2 PI1.1)

You set out and communicate what your processing is meant to do: data definitions, product specifications, the rules for each calculation. Without this, nothing else in the category can be tested, because the auditor needs a specification to test against.

Inputs, processing and outputs (SOC 2 PI1.2 to PI1.4)

You control inputs so that what enters the system is complete and accurate against the specification (SOC 2 PI1.2). You control processing so that it runs completely, accurately, on time and only as authorised (SOC 2 PI1.3). You control outputs so that they are complete, accurate, on time and reach only the people meant to receive them (SOC 2 PI1.4).

Storage (SOC 2 PI1.5)

You store inputs, items still in processing and outputs completely and accurately, for as long as your specifications say.

Where change management comes in

A change to calculation logic can break integrity silently. SOC 2 CC8.1 applies to every change, and with Processing Integrity in scope the auditor will look harder at how you test changes to the rules that produce customer results.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 15-person payroll software company in Glasgow publishes a data dictionary and calculation rules to its customers. Uploaded timesheets pass validation that rejects malformed rows and reports each rejection back to the customer, who fixes and resubmits.

Every payroll run reconciles record counts and control totals at each stage, from import to calculation to payment file. Any difference stops the run and lands in an exceptions queue that a named analyst clears the same day, recording the cause. Failed jobs alert the on-call engineer. Payment files go only to each customer’s nominated bank channel, and inputs and outputs are kept for the period the contracts set.

Changes to tax or pension rules run against a regression pack of known cases before release, and a second person approves the results. Each quarter the operations lead reviews the exceptions log for recurring causes and records what was fixed.

Evidence an auditor expects

The criteria name no documents; these are what auditors usually sample for PI1.

Processing specifications: data definitions and calculation rules, approved and shared with customers.
Input validation: the rules, and logs of rejected inputs and how they were handled.
Reconciliations: control totals or record counts at each stage, with sign-off for a sample of runs.
Exceptions log: each processing error, its cause and its resolution.
Job monitoring: alerts for failed or late processing, and responses to them.
Output distribution: controls that send outputs only to intended recipients.
Retention of inputs and outputs: configuration that matches your specifications.
Regression test results: for changes to processing logic, approved before release.

Common mistakes

Adding the category without a specification

Teams add Processing Integrity because it sounds reassuring, then cannot say what “correct” means. Write the specification first; if you cannot, the category is not ready.

Reconciliations that leave no trace

A reconciliation run by a script that nobody checks, with no stored result, is invisible to the auditor. Store each result and record who reviewed the exceptions.

An exceptions queue with no owner

Errors that sit in a queue for weeks make the “timely” part of the criteria fail. Name an owner and a target time to clear it.

Taking on the customer’s data quality

If your system description promises the accuracy of what customers upload, you have taken on a control you cannot run. Say what you validate, and list source-data accuracy as a customer control.

How Sted helps

For the SOC 2 processing integrity criteria Sted’s knowledge base maps the Production and Process Controls Procedure (PRC-PPC), with the Production and Process Control Framework Record (REC-PPCF), Nonconforming Output Record (REC-NCO) and Process Validation Record (REC-PVR); storage of inputs and outputs (PI1.5) also maps to the Backup, Data Retention and Erasure, and Information Classification policies.
The procedure covers production and operational processes in general; your own processing rules are yours to add.
In edit mode you can add your own requirements and sections and drop recommended sections; standard sections cannot be dropped.
Records follow templates with sections and, where useful, structured fields you can report on.
Records are part of the Full Management System plan.
A record is opened, completed, submitted for closure and closed (or withdrawn); closure is reviewed by the document owner.

Sted does not check your processing, run reconciliations or test calculation changes. The procedure in Sted’s knowledge base is general, so expect to add your own processing rules to it.

The SOC 2 hub: choosing the categories for your report.
SOC 2 security and the common criteria: change management under CC8.1, which this category leans on.
Working with your SOC 2 auditor: listing the controls your customers own.
SOC 2 evidence: populations of processing runs and how auditors sample them.
Control: a control as the auditor tests it.

Frequently asked questions

Do we need Processing Integrity in our SOC 2 report?

Only if customers rely on the results your system produces, not just on it storing their data. Payroll, payments, billing, claims and data pipelines are the usual cases. If no customer has asked and your contracts promise nothing about the accuracy of processing, leave it out.

Are we responsible for the accuracy of data our customers enter?

No, not beyond the checks you say you perform. The criteria cover your processing: you validate inputs as your specifications say, process them correctly and deliver correct outputs. Checking that the source data is right is usually a control your customers own, listed as a complementary user entity control.