What Processing Integrity actually requires
The AICPA Trust Services Criteria for Processing Integrity define the controls that demonstrate system processing produces complete, valid, accurate, timely, and authorised results. The criterion is published as part of the AICPA TSP Section 100 framework available at aicpa.org and covers five domain areas: data input validation, processing logic accuracy, output completeness verification, error handling and exception management, and processing change management. The control set is layered on top of the Security Common Criteria; a Processing Integrity scope means the auditor tests the Common Criteria plus the Processing Integrity criteria during the same engagement.
The reason Processing Integrity is materially more expensive than Availability or Confidentiality is that the controls must be tailored to the SaaS's specific processing logic. The auditor must understand the SaaS's calculation methodology, business rules, and exception handling in depth to test that processing produces correct results. For a tax preparation SaaS, this means understanding the tax calculation logic. For a payroll SaaS, this means understanding the wage and tax withholding logic. For a healthcare claims processing SaaS, this means understanding the claim adjudication logic. The auditor's testing approach typically includes sample data input testing where the auditor provides known inputs and verifies the output matches expected results, which is closer to a software audit than a typical SOC 2 control test.
What the marginal cost actually depends on
There is no published figure for what Processing Integrity adds, because no CPA firm publishes a SOC 2 rate card of any kind and a criterion add-on is one component of a fee set per engagement. Anyone quoting a precise add-on split by firm tier is quoting a number nobody published. The mechanism is knowable, though, and for this criterion it explains why it sits at the expensive end.
Availability and Confidentiality are cheap to add because their controls mostly already exist and the work is documentation. Processing Integrity is different in kind: the criterion is bespoke to what your system actually processes, so the control set has to be designed around your business rules, your exception handling and your reconciliation logic. Very little of it is reusable from the Security work you have already done. The readiness effort concentrates on documenting processing logic that most teams have never written down, and fieldwork typically pulls in engineering time to walk the auditor through it, which the other criteria rarely do. To get your real number, ask one firm to quote Security only and Security plus Processing Integrity against the same written scope; the gap is the answer for your system, and it will vary more between companies than any other criterion.
When to scope Processing Integrity in
The scoping decision for Processing Integrity is materially different from Availability and Confidentiality because the criterion is genuinely bespoke per SaaS. The clearest scope-in scenarios are SaaS where the customer's downstream business decisions depend on the SaaS's calculated outputs being correct. Examples include: tax preparation SaaS where the customer files tax returns based on the SaaS's calculations; accounting SaaS where the customer's financial reporting depends on the SaaS's bookkeeping; payroll SaaS where employees are paid based on the SaaS's wage and tax calculations; healthcare claims processing platforms where insurance reimbursements depend on the SaaS's claim adjudication; transaction processing platforms where customer payments depend on the SaaS's transaction handling; regulatory reporting platforms where the customer's regulatory submissions depend on the SaaS's data aggregation and formatting.
In these scenarios, Processing Integrity scope provides the customer's procurement team with objective evidence that the SaaS has tested controls supporting calculated output correctness, which is what enterprise procurement is looking for in vendor risk reviews of processing-critical SaaS. Without Processing Integrity scope, the customer has the SaaS's marketing claims about output correctness but no third-party-attested operational verification.
When to skip Processing Integrity and stay with Security only or Security plus Availability
Most B2B SaaS can skip Processing Integrity. The criterion does not provide additional procurement signal for SaaS where the value is communication (Slack, Zoom, Notion), collaboration (Figma, Miro, Asana), data storage (Box, Dropbox, S3-equivalent), workflow automation (Zapier, n8n), CRM (Salesforce, HubSpot), marketing automation (Marketo, Pardot), or developer tooling (GitHub, GitLab, CI/CD platforms). For these SaaS, the customer is not relying on the SaaS to produce calculated outputs that downstream business decisions depend on; the customer relies on the SaaS to provide a platform for the customer's own work.
Adding Processing Integrity scope without customer-facing demand for it is over-spend, and because this is the criterion whose controls have to be purpose-built, it is the most expensive kind of over-spend available in a SOC 2 scope. The right scoping for typical B2B SaaS is Security plus Availability plus Confidentiality, with Processing Integrity and Privacy as later additions only if the customer base or regulatory environment specifically requires them.
Specific controls to implement or formalise
The control set that satisfies Processing Integrity TSC requirements is more bespoke than for other criteria because the controls map to the SaaS's specific processing logic. The general control areas are: documented input validation rules with explicit reject or quarantine procedures for invalid data; processing logic documentation including all business rules, calculation methodology, and decision trees that affect output (this is the heaviest lift for SaaS that has not previously documented its processing logic explicitly); output verification procedures including reconciliation routines, totals checks, and sample audits that the operations team performs periodically; exception handling procedures with documented escalation paths and remediation timelines; change management procedures specifically for processing logic changes including testing requirements, peer review, and rollback procedures; processing-specific monitoring including failed batch processing alerts, calculation anomaly detection, and processing-time SLA tracking; audit logging of processing activities with retention sufficient for the audit observation period (typically 12 months for Type 2). Engineering team time is the dominant marginal cost; budget for engineering hours rather than just GRC manager hours.
The AI/LLM SaaS edge case
AI SaaS that processes customer queries through large language models or other ML systems is an edge case where Processing Integrity scope is sometimes considered but rarely scoped successfully. The challenge is that the AICPA TSC for Processing Integrity were written for deterministic processing logic (input X produces output Y) and the testing approach assumes the auditor can verify processing correctness through known-input testing. AI/LLM systems are not deterministic in the same way; the same input may produce different outputs across model versions, and the concept of correctness is harder to define for natural language outputs than for tax calculations.
Most AI SaaS today scope SOC 2 Security only and supplement with separate frameworks for AI-specific control coverage: NIST AI Risk Management Framework, ISO 42001 (AI management system), or model-card and data-card disclosures. Buyers of AI SaaS who want third-party-attested model behaviour controls are usually better served by these alternative frameworks than by trying to fit AI processing into the AICPA Processing Integrity TSC. The AI SaaS SOC 2 cost page covers this in more depth.
How Processing Integrity fits with the other optional criteria
Processing Integrity is rarely scoped in isolation. SaaS that adds Processing Integrity typically already has Availability and Confidentiality in scope, because the customer base that demands processing correctness verification typically also demands availability and confidentiality verification. Each criterion added to one engagement adds its own control points and testing hours on top of the Security baseline, and no firm publishes what any of that costs. Privacy may also be in scope for processing-critical SaaS that handles personal data, particularly in healthcare and fintech verticals.