What it is
SOC 2 reports can cover five Trust Services Categories. Security is the only one every report must include. Processing integrity is optional. When it is in scope, the auditor tests whether your system processes data completely, validly, accurately, on time and only when authorized. That is a different question from whether the system is locked down or online.
A system can pass a security audit and still send a customer the wrong total. It can be available all month and still drop rows from a nightly batch. Processing integrity looks at the work itself: what goes in, what happens to it, what comes out and what you store. The criteria are PI1.1 through PI1.5. They cover the definitions and specifications you use, controls over inputs, controls over processing, controls over outputs and controls over storage.
It fits services where the output drives a decision or a transaction. Billing engines, payroll platforms, claims processing, inventory systems, reporting tools and data pipelines are common examples. If a customer takes your number and posts it in their own books, processing integrity is usually worth a conversation.
How it works
You start with the system description. Name the service, the system boundary and the processing objective. Say what a correct unit of work looks like: one invoice, one claim, one file, one nightly load. State the accuracy and timeliness you promise. Vague wording like high quality gives the auditor nothing to test.
For inputs, auditors look for validation rules, required fields, duplicate checks and approval before a batch is accepted. They also look for reconciliations at the door: record counts, hash totals or control totals that show nothing was lost between the source and your system. An exception queue with an owner is stronger evidence than a dashboard nobody reads.
For processing, they look at job scheduling and monitoring, retry logic, idempotency keys and dead letter queues for failed messages. Calculation logic needs change control and regression tests, because a small code change can alter every output. Segregation of duties matters when one person can change a rule and approve the result.
For outputs, they check delivery logs, timestamps and a review before release. They want a correction procedure for errors found after delivery: who reports it, who fixes it, how you reprocess and how you record the root cause. Storage controls cover retention and integrity of inputs, work in progress and outputs. Auditors sample batches or transactions and trace them through these controls. A Type II report tests whether the controls ran across the period, not just whether they exist on paper.
Why it matters for a business
Errors in processing are quiet. A wrong rate, a skipped file or a late feed may not crash anything. It just produces a bad output that a customer acts on. The cost shows up later as manual cleanup, credits, rework and lost confidence. Processing integrity controls are mostly about catching those failures before the customer does.
It also affects sales. When your service feeds a customer's financial reporting, payroll or inventory, their auditor may ask how they know your output is complete and accurate. A SOC 2 report with processing integrity in scope gives them a documented answer. A report that leaves it out can push the customer into extra testing or into a harder conversation with their own auditors.
The trade-off is real. Adding processing integrity widens the scope, adds criteria, adds evidence and can add audit time. Do not add it just to make the report look bigger. Add it when the service produces an output that matters and when you can define accuracy and timeliness in a way you can measure. Weak controls inside an in-scope category are worse than a clean report with a narrower scope.
Common mistakes
The first mistake is treating security controls as processing integrity. Encryption, access reviews and vulnerability scans are useful, but they do not show that a batch was complete. The auditor needs evidence tied to the data and the work: reconciliations, exception logs, approvals and correction records.
The second is having no definition of correct. If nobody can say what a complete file or an accurate invoice looks like, the audit turns into a debate. Write the processing objective down before you pick controls. Include timeliness. A report that promises accuracy but never measures when output arrived is hard to support.
The third is testing only the happy path. Real operations include rejected inputs, failed jobs and reprocessing. If your team cannot show what happens when a file fails, the control looks untested. Keep a failed batch walkthrough ready.
Other common gaps: claiming perfect accuracy with no measurement, relying on a dashboard with no review sign-off, forgetting manual steps and spreadsheets, and leaving a subservice organization out of the description. Over-scoping every system in the company also creates work you cannot sustain. Pick the service and the boundary.
How to get started
Pick one service and one system. Write a one-page processing objective: the inputs, the main steps, the outputs, the timing and the definition of correct. Then list the controls you already have for PI1.1 through PI1.5. Give each control an owner, a frequency and the evidence it leaves behind.
Run a small gap review with real samples. Pull three recent batches or transactions and trace each one from input to output. Note where the trail goes cold. If you find no reconciliation, add one. If failed jobs vanish without a ticket, add an exception log and a correction step. Test a failed batch on purpose so the team knows the procedure.
Decide early whether processing integrity belongs in your report. Talk to your auditor about scope and report type before you write policies. You can handle this internally, bring in a consultant or use a fixed price package. The Cloudverg SOC 2 readiness assessment is $7,500 and runs three weeks. It covers scoping, a gap assessment, a policy and evidence inventory and a remediation roadmap. Compare it with other options and pick what fits your team.
Frequently asked questions
Is processing integrity required for SOC 2?
No. Security is the only Trust Services Category every SOC 2 report must cover. Processing integrity is optional. You include it when the system produces outputs that customers rely on and when you can define and test accuracy and timeliness.
What does processing integrity cover that security does not?
Security asks whether the system is protected from unauthorized access and other threats. Processing integrity asks whether the work is complete, valid, accurate, timely and authorized. A system can be secure and still produce a wrong invoice or a late file.
How does an auditor test processing integrity?
The auditor reads the system description, walks through the controls and samples transactions or batches. Evidence includes reconciliations, job logs, exception tickets, change records and correction reports. In a Type II report, the auditor tests whether those controls operated across the review period.