Processing integrity is the SOC 2 category teams are least sure about. The name sounds like something every software company should have. The criteria read like a description of any data pipeline. It is tempting to include it to look thorough.
The useful question is narrower: do your customers rely on the correctness of what your system produces, in a way you have promised? If they do, processing integrity is how your report says so. If they do not, it is a category full of controls that no reader needs, each one a chance for an exception.
This article covers who the category is for, what its criteria look like as real controls, and how to decide.
What processing integrity covers, and what it does not
The AICPA's trust services criteria describe processing integrity as system processing that is complete, valid, accurate, timely, and authorized to meet your objectives. The five criteria, PI1.1 to PI1.5, follow data through the system: specifications, inputs, processing, outputs, and storage. The trust services criteria explained one by one lists them in summary.
Three things it is not:
It is not tamper protection. Stopping unauthorized changes to data is a security concern, and it sits in the common criteria. What the SOC 2 security criterion actually requires covers those.
It is not the quality of your customers' data. You are responsible for processing what you receive as specified, and for controls over how inputs are accepted. You are not attesting that customers sent correct data.
It is not code quality in general. Testing and change approval are CC8. Processing integrity asks whether the running system produces the results you promised, every time it runs.
The five words in the definition
Each word in "complete, valid, accurate, timely, and authorized" points at a different failure, and it helps to test your service against each one:
Complete. Every record that should be processed was processed. Nothing was dropped silently.
Valid. Records that should have been rejected were rejected, rather than processed as if they were correct.
Accurate. Calculations and transformations produce the right result.
Timely. Processing finished when you said it would. A correct payroll run delivered a day late is still a failure against your commitments.
Authorized. Only requests that should be processed were processed, and manual adjustments were approved.
Timeliness and authorization are the two that teams forget to design controls for.
Who needs it: services where the output is the product
Processing integrity fits when your customers act on your output without recalculating it. Typical examples:
Payroll and benefits administration
Billing, invoicing, and usage metering
Payment processing and reconciliation
Claims processing and adjudication
Tax calculation and filing services
Data transformation pipelines that feed customers' own reporting
A quick test: if your system produced a wrong figure, would your customer pay, file, or report it before noticing? Would your contract treat that error as your failure? Two yes answers suggest processing integrity belongs in scope.
Services that usually do not need it include collaboration tools, developer tooling, and infrastructure where customers run their own processing on your platform. Your service may process data in those cases, but correctness of the result is not what you sell.
Some cases are genuinely borderline, such as analytics products or workflow tools. For those, let your contracts and your buyers decide. If no buyer has asked about processing integrity, that is information.
Where SOC 1 comes in
If your processing affects your customers' financial statements, their financial auditors may want a SOC 1 report, which covers controls relevant to user entities' internal control over financial reporting. A payroll or billing service may be asked for both. Processing integrity in a SOC 2 does not replace a SOC 1 for that purpose, so confirm which report your customers' auditors need before you scope either.
What the five criteria look like as controls
The criteria are general. The controls are specific to your product, which is the main reason this category takes more thought than the others. Say a hypothetical 60-person company runs a usage-based billing engine that calculates invoices for its customers' end users. Its controls might look like this:
PI1.1, specifications. Calculation rules, data definitions, and rounding behavior are documented and published to customers. Changes to them are versioned and communicated before they take effect.
PI1.2, inputs. Usage records are validated on arrival against a schema. Malformed records go to an error queue rather than being dropped, and the queue is worked to empty. Record counts from the source are reconciled against counts ingested.
PI1.3, processing. Each billing run is monitored for completion within its scheduled window. Totals are reconciled against the inputs, and variances above a threshold stop the run until someone reviews them.
PI1.4, outputs. Invoice totals are reviewed before release, delivery is confirmed, and outputs are available only to the intended recipient.
PI1.5, storage. Inputs, intermediate results, and outputs are retained long enough to reprocess or investigate a disputed invoice, and stored so they cannot be altered without a record.
The evidence follows from the controls: reconciliation reports with a reviewer's sign-off, error queue tickets, job run logs, and release approvals. Automated controls help a great deal, because an auditor can test the configuration and a sample of runs rather than a stack of manual checklists. Types of audit evidence and which is strongest covers why system-generated records carry more weight.
Why it costs more than it looks
Processing integrity is usually the most product-specific category in a SOC 2. That has consequences:
No template fits. Your controls describe your processing. Policy templates and generic control libraries help little here.
Engineering owns the controls. The people who operate them are product and data engineers, not the security team. They need to understand that their reconciliations are now audit evidence.
The auditor has to understand your system. Expect walkthroughs of how data moves, and tests that trace a sample of transactions from input to output.
Errors become exceptions. A billing run that went out with a wrong total during the period is an incident in your operations and a likely exception in your report.
The system description grows. Your description has to explain the processing well enough that a reader understands what the controls protect.
None of this makes the category a bad choice. It makes it a deliberate one.
Questions to answer before you include it
Work through these with whoever owns the product and whoever signs customer contracts:
What processing do we promise? Is there a written specification that a customer can read, and would an auditor recognize it as the standard you are held to?
Do customers rely on our output without checking it? If they always reconcile your results themselves, the reliance is weaker.
Would a processing error breach a contract? Look for accuracy warranties, service credits, and indemnities tied to errors.
Are our processing controls automated and logged? Manual checks with no record will be hard to evidence for a full Type II period.
Do buyers ask for it? Check the questionnaires and contract requests that prompted the audit.
If the answers point to inclusion but your controls are not yet logged, a Type I report first can surface design gaps while the stakes are low. SOC 2 Type I vs Type II covers that choice. The SOC 2 framework page has the surrounding context.
How TrustLynce helps
TrustLynce maps your controls to the processing integrity criteria alongside the common criteria through compliance automation, so a reconciliation that also supports another framework is evidenced once. Tracking customer commitments against controls shows which contractual accuracy promises each control is meant to support.