SOC 2 Processing Integrity Criteria: Do You Need It and What Do Auditors Actually Test

Introduction

When a SaaS company begins scoping its SOC 2 audit, the first five criteria that appear in every conversation are the Common Criteria — the Security trust service category that covers logical access, change management, and monitoring. Security is mandatory. Everything else is optional, chosen based on whether the criteria are relevant to the services your platform delivers to customers.

Processing Integrity is one of those optional categories, and it is consistently one of the most misunderstood. Some engineering teams include it reflexively because it sounds important. Others skip it without evaluating whether their platform actually warrants it. Both approaches carry risk — the first inflates audit cost and scope without proportional value, and the second can leave a meaningful gap in your compliance posture if your product genuinely performs calculations or transforms data that customers rely on for business decisions.

This guide explains exactly what Processing Integrity means under SOC 2, which types of SaaS products need it, what controls each of its five sub-criteria requires, what evidence auditors collect during a Type 2 review, and how to make a defensible scoping decision before your next audit cycle.

What Processing Integrity Means Under SOC 2

Processing Integrity is one of the five Trust Services Criteria (TSC) defined by the AICPA. The other four are Security, Availability, Confidentiality, and Privacy. While Security addresses who can access your systems, Processing Integrity addresses what your systems do with data once it enters them.

The AICPA's definition is precise: Processing Integrity means that system processing is complete, valid, accurate, timely, and authorized. These are not abstract ideals — they map directly to five sub-criteria (PI1.1 through PI1.5) that auditors use as a framework for testing your controls.

In practical terms, Processing Integrity asks and answers a specific question: when data enters your system, does it come out correctly on the other side? This covers the full lifecycle of a processing transaction — from the moment an input is received, through every transformation, calculation, or routing step, to the final output delivered to a customer or downstream system. If any step in that chain introduces errors, delays, or unauthorized changes, and your system has no mechanism to detect and correct them, you have a Processing Integrity gap.

Critically, Processing Integrity is about the reliability of your processing logic, not the confidentiality or availability of the underlying data. A system can have excellent encryption and 99.9% uptime and still fail Processing Integrity if it produces incorrect outputs without detecting or reporting the discrepancy.

Which SaaS Products Need Processing Integrity — and Which Do Not

The scoping decision for Processing Integrity comes down to a single question: does your platform perform processing that customers rely on for accuracy in ways that have material consequences if that processing is wrong?

Products That Typically Require Processing Integrity

Financial technology platforms are the clearest case. If your product calculates interest, fees, payments, loan balances, or any financial figure that customers use for accounting, tax reporting, or customer billing, incorrect outputs have direct financial consequences. Auditors and customers expect Processing Integrity in scope.

Payroll and HR automation platforms that calculate gross pay, deductions, withholdings, and net pay are equally clear. A calculation error does not just affect a database record — it affects an employee's paycheck and a company's tax compliance.

Analytics and reporting platforms that aggregate, transform, and present business intelligence data to customers fall into scope if customers use those outputs to make operational or financial decisions. If a customer's revenue dashboard shows incorrect figures because of a processing error in your aggregation pipeline, and they make business decisions on that data, that is a Processing Integrity failure.

Healthcare platforms performing clinical calculations — drug dosage computations, lab result normalization, risk scoring — carry the highest stakes. Incorrect processing here carries patient safety implications, and Processing Integrity controls are expected by sophisticated buyers in this space.

E-commerce and marketplace platforms that calculate taxes, commissions, refunds, or inventory quantities are also strong candidates, particularly if sellers or buyers rely on those figures for reconciliation.

Products That Typically Do Not Need Processing Integrity

Collaboration and productivity tools — project management software, document editors, communication platforms — primarily store and retrieve data rather than transform it. The system is a container, not a calculator. Processing Integrity is generally not relevant.

Content management systems and CMS-adjacent platforms that receive content, store it, and serve it back without transformation do not perform the type of processing this criteria addresses.

Authentication and identity platforms whose primary function is access control rather than data transformation are typically outside scope.

Simple SaaS storage or workflow tools where the customer defines the logic and your platform executes it without adding its own transformations are borderline cases. The key test is whether your system's processing logic — not the customer's — could introduce errors that affect outputs.

The honest scoping test is this: if your processing logic produced wrong outputs for a week, would your customers notice? Would it affect their financials, their customers, or their compliance? If the answer is yes, Processing Integrity belongs in scope.

The Five Sub-Criteria and the Controls Each Requires

When Processing Integrity is in scope, auditors evaluate your environment against five sub-criteria. Each maps to a specific set of controls that must be documented, implemented, and demonstrably operating throughout the audit period.

PI1.1 — Completeness

This sub-criterion addresses whether all transactions and data inputs that should be processed are actually processed — no records dropped, skipped, or silently lost.

Controls required under this sub-criterion include input reconciliation procedures that verify record counts between source and destination systems, job completion monitoring that confirms batch processes ran in full, message queue monitoring that detects dropped or unacknowledged messages, and alerting on processing job failures or partial completions. Documentation should include reconciliation logs, job execution records, and alert configurations.

A common technical implementation is a reconciliation script that runs after each batch processing job, compares the row count in the source dataset against the row count written to the output table, and raises an alert if the counts do not match. Auditors will ask for samples of these reconciliation logs across the audit period.

PI1.2 — Accuracy

Accuracy addresses whether data is processed correctly — calculations produce the right results, transformations apply the correct logic, and outputs match expected values.

Controls required include input validation rules that reject or flag malformed or out-of-range data before it enters processing pipelines, automated unit and integration tests covering critical calculation logic, reconciliation checks that compare processing outputs against expected values or control totals, and defined procedures for investigating and correcting calculation errors when discovered.

For a financial platform, this might mean automated tests that run on every deployment to verify that interest calculations for a set of known inputs produce the expected outputs. Auditors will review your test coverage for processing logic, your deployment pipeline, and your exception resolution records.

PI1.3 — Timeliness

Timeliness addresses whether processing is completed within defined timeframes and whether delays are detected and communicated.

Controls required include defined SLAs or internal processing time targets for each processing workflow, monitoring that detects when processing jobs exceed their expected duration, alerting when processing falls outside acceptable windows, and documented procedures for investigating and communicating delays to affected customers.

This sub-criterion is more relevant for near-real-time systems — payment processors, data streaming pipelines, and report generation systems — than for batch systems with generous processing windows. Auditors will ask for your defined processing SLAs, evidence of monitoring configurations, and samples of any delay incidents and how they were handled.

PI1.4 — Authorization

Authorization under Processing Integrity addresses whether processing is initiated only by authorized parties and whether unauthorized processing attempts are detected and blocked.

This is distinct from the access control requirements in the Common Criteria. Where CC6 focuses on who can log into your system, PI1.4 focuses on whether processing workflows themselves can only be triggered by authorized inputs, users, or systems. Controls required include input validation that verifies the source and authorization level of processing requests, audit logs that record who or what initiated each processing job, segregation of duties for manual processing overrides, and alerting on processing attempts from unauthorized sources.

For an API-driven platform, this means validating that every processing request carries a valid, scoped authentication token and that tokens with insufficient permissions are rejected before processing begins — not just at the API gateway, but at the processing layer itself.

PI1.5 — Validity

Validity addresses whether inputs are complete, well-formed, and within acceptable parameters before they enter the processing pipeline. This sub-criterion overlaps with accuracy but focuses specifically on the intake stage — catching bad data before it propagates through your system.

Controls required include defined validation schemas for all processing inputs, automated validation checks that run before data enters processing queues, exception handling procedures for invalid inputs that include logging, alerting, and defined remediation paths, and documentation of validation rules and their business justification.

A practical implementation is a schema validation layer that sits at the boundary between your ingestion API and your processing pipeline. Every incoming payload is validated against a JSON Schema or equivalent definition before it is accepted. Invalid payloads are rejected with a structured error response, logged to an exception table, and surfaced in an operations dashboard. Auditors will review your validation schemas, exception logs, and evidence that invalid inputs do not silently enter your processing pipeline.

What Evidence Auditors Actually Collect

Understanding the evidence auditors request for Processing Integrity helps you build the right documentation infrastructure before the audit begins — rather than scrambling to reconstruct evidence retroactively.

For a SOC 2 Type 2 engagement, auditors will sample evidence from across the entire review period, not just the point in time when the audit fieldwork occurs. The following are the primary evidence categories they will request.

Processing workflow documentation. Auditors will ask for written descriptions of each in-scope processing workflow — what data enters, what transformations occur, what outputs are produced, and what system components are involved. This does not need to be a formal specification, but it needs to be accurate and current. Outdated documentation that does not match your actual architecture is a red flag.

Reconciliation logs and reports. For each reconciliation control you have implemented, auditors will sample logs across the review period to confirm the control operated consistently. They will look for both successful reconciliations and evidence of how exceptions were handled when reconciliation counts did not match.

Exception and error reports. Auditors will request samples of your exception logs, processing error reports, and any dashboards or alerting systems that surface processing anomalies. They want to see that exceptions are captured, that they are reviewed by a responsible party, and that they are resolved through a defined procedure within a reasonable timeframe.

Test evidence for processing logic. For accuracy controls, auditors will review evidence that your critical processing logic is tested — unit test results, integration test outputs, or QA sign-off records. They will also look for evidence that tests are run as part of your deployment process so that changes to processing logic do not bypass validation.

Incident records for processing failures. If any processing errors or delays occurred during the audit period, auditors will expect to see incident records documenting the detection, investigation, root cause, and resolution. An environment with no processing incidents and no records is suspicious. An environment with incidents that are well-documented and resolved promptly demonstrates a mature control posture.

Monitoring and alerting configurations. Auditors will ask for screenshots or exports of your monitoring dashboards, alert configurations, and on-call runbooks. They want to confirm that monitoring is active and covers the processing workflows in scope — not just configured once and forgotten.

How to Decide Whether to Include Processing Integrity in Scope

The decision framework is straightforward when you work through it systematically.

Start by inventorying every processing workflow your platform performs — anything that takes data in, transforms it, calculates something, or produces an output that customers consume. For each workflow, ask: what happens to a customer if this processing produces a wrong result? If the answer involves financial loss, regulatory exposure, incorrect reports that drive decisions, or failed transactions, that workflow is a candidate for Processing Integrity scope.

Next, assess your current control maturity. Do you have reconciliation procedures? Do you have validation logic at your data ingestion boundary? Do you have monitoring that detects processing failures? If your processing is currently a black box — jobs run, outputs appear, and you only discover errors when customers complain — the work required to implement Processing Integrity controls is significant. That work may be worth doing for security and reliability reasons independent of compliance, but you should plan for it in your audit timeline.

Finally, consider your customer base and competitive positioning. Enterprise buyers in financial services, healthcare, and regulated industries increasingly expect Processing Integrity in scope for any platform that touches their transaction data. If your sales team is losing deals because prospects ask whether your SOC 2 covers Processing Integrity and the answer is no, that is a signal the investment pays off in pipeline impact.

If your platform primarily stores and retrieves data without material transformation, the Common Criteria plus Availability and Confidentiality are likely sufficient. Adding Processing Integrity to a scope where it does not apply adds audit cost without adding meaningful assurance — and sophisticated customers will recognize that.

Conclusion

Processing Integrity is one of the most precisely defined Trust Services Criteria in the SOC 2 framework, and it is one of the easiest to scope correctly when you understand what it is actually testing. It is not about data security, availability, or access control — it is specifically about whether your system's processing logic produces complete, accurate, timely, authorized, and valid outputs, and whether you have the controls and monitoring in place to detect and correct it when it does not.

The five sub-criteria — completeness, accuracy, timeliness, authorization, and validity — each translate into concrete technical controls: reconciliation procedures, validation schemas, monitoring configurations, test coverage, and exception handling workflows. Auditors evaluate whether those controls existed and operated consistently throughout the review period, which means the documentation and evidence infrastructure needs to be in place before the audit window opens.

If your platform performs calculations, automates transactions, or transforms customer data in ways that affect decision-making, Processing Integrity belongs in scope and the controls required to support it will strengthen your platform's reliability as a side effect. If your platform is primarily a storage and retrieval system, the Common Criteria are likely sufficient and adding Processing Integrity inflates cost without proportional assurance value.

For a complete understanding of how Processing Integrity fits within the broader SOC 2 framework — including the Common Criteria, the audit process, and how to build a compliance program from the ground up — read our full guide on SOC 2 Compliance: A Complete Guide for SaaS Companies in 2026.

This content was generated by AI.