Customers who depend on a service to calculate, move or transform their data, such as payroll, payments, billing, claims, data pipelines or AI scoring, need assurance that the output is right, not just that the system is secure, and the SOC 2 Processing Integrity category is the only part of the report that tests this. This guide works through the five Processing Integrity criteria, PI1.1 to PI1.5, in the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022): what each asks, the controls service organisations design for inputs, processing, outputs and storage, the evidence auditors sample in a Type 2, and how the criteria apply to payment flows, ETL pipelines and AI systems. It is written for engineering, data and compliance leads at service organisations deciding whether to add Processing Integrity or preparing for a report that includes it. Criterion wording is summarised from the AICPA text, which is a download behind a free AICPA account; check the official document before relying on detail.
Source note: criteria and point-of-focus titles are summarised from the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022) as reproduced by a secondary reference; evidence examples and the AI pipeline interpretation are practitioner norms, not AICPA requirements. On 28 October 2026 the AICPA published exposure drafts of proposed 2027 Trust Services Criteria, adding points of focus on AI topics such as model monitoring, data poisoning and transparency of AI-generated outputs, with comments due 15 January 2027 and a proposed effective date for engagements beginning on or after 31 December 2027 if approved. Those proposals are not in force, and their exact effect on the PI criteria was not confirmed for this guide. Confirm against the official text before relying on it.
Key takeaways
- Five criteria follow the data. PI1.1 specifications and quality information, PI1.2 inputs, PI1.3 processing, PI1.4 outputs and PI1.5 storage, each with its own points of focus.
- Integrity here means processing, not data at rest. Processing Integrity asks whether processing is complete, valid, accurate, timely and authorised against your specifications; it is not a substitute for Security controls over tampering.
- Specifications are the test baseline. Without written definitions of inputs, processing rules and expected outputs, the auditor has nothing to test accuracy against, so PI1.1 work comes first.
- Reconciliation and error queues are the core evidence. Control totals, record counts, exception reports and their resolution over the whole period are what most PI testing samples.
- AI systems fit, with care. Probabilistic outputs can be in scope if you define acceptable accuracy, monitor it and handle exceptions; promising exact correctness for model outputs creates exceptions.
When Processing Integrity belongs in the report
The Trust Services Criteria have five categories; Security (CC1 to CC9) is always included and Availability, Processing Integrity, Confidentiality and Privacy are optional. Processing Integrity is the least commonly selected, because many SaaS products store and display data rather than compute results customers rely on. See the SOC 2 Guide for the examination overall.
- Include it when: the service produces numbers or decisions customers act on or report from (payroll, tax, invoicing, payments, claims adjudication, trading, data transformation for customer analytics), when customers' own auditors rely on your output for their financial reporting, or when contracts commit to processing accuracy or timeliness.
- Usually leave it out when: the product is a storage, collaboration or security tool where customers create and consume the data themselves. Security, Availability and Confidentiality answer most of their questions.
- SOC 1 or SOC 2: if customers need assurance over controls relevant to their financial statements, a SOC 1 report is the usual vehicle; Processing Integrity in SOC 2 suits broader operational accuracy commitments. Some providers carry both.
The criteria and points of focus
| Criterion | What it requires (AICPA wording, condensed) | Points of focus |
|---|---|---|
| PI1.1 | Obtains or generates, uses and communicates relevant, quality information about processing objectives, including definitions of data processed and product and service specifications | Identifies information specifications; Defines data necessary to support a product or service; Defines information necessary to support the use of a good or product |
| PI1.2 | Implements policies and procedures over system inputs, including controls over completeness and accuracy | Defines characteristics of processing inputs; Evaluates processing inputs; Creates and maintains records of system inputs |
| PI1.3 | Implements policies and procedures over system processing to result in products, services and reporting that meet objectives | Defines processing specifications; Defines processing activities; Detects and corrects processing or production activity errors; Records system processing activities; Processes inputs |
| PI1.4 | Implements policies and procedures to make available or deliver output completely, accurately and timely in line with specifications | Protects output; Distributes output only to intended parties; Distributes output completely and accurately; Creates and maintains records of system output activities |
| PI1.5 | Implements policies and procedures to store inputs, items in processing and outputs completely, accurately and timely in line with specifications | Protects stored items; Archives and protects system records; Stores data completely and accurately; Creates and maintains records of system storage activities |
Controls and evidence by criterion
PI1.1: specifications
- Controls: data dictionaries and schemas for inputs and outputs; documented processing rules (calculation logic, rounding, currency and time zone handling, cut-off times); service specifications customers can see, such as API documentation and file format specifications; versioning of all of these under change management.
- Evidence: the current specifications, their change history in the period, and proof they were communicated to customers. See the Data lineage, data quality and data contracts as security controls guide for data contracts as a way to make specifications enforceable.
PI1.2: inputs
- Controls: schema and range validation at every ingestion point (API, file upload, message queue); rejection or quarantine of invalid records with a reason code; duplicate detection using idempotency keys; batch control totals and record counts agreed between sender and receiver; an input log keyed by batch or request ID.
- Evidence: validation rule configuration, a sample of rejected inputs and their handling, and reconciliation of received against expected counts for sampled days.
PI1.3: processing
- Controls: automated tests of processing logic in the release pipeline; job scheduling with dependency checks; run-to-run reconciliations (opening balance plus movements equals closing balance); error and exception queues with owners and ageing; processing logs recording job, version and inputs used.
- Evidence: job monitoring records, exception queue reports and resolution tickets across the period, reconciliation sign-offs, and change tickets showing logic changes were tested and approved (with CC8.1). See the Change Management Security guide.
PI1.4: outputs
- Controls: output totals reconciled to processing totals before release; delivery only to authorised recipients (per-customer storage paths, signed URLs, authenticated APIs); delivery confirmations and retry handling for missed deliveries; an output log.
- Evidence: reconciliation records, recipient configuration reviews, delivery logs and missed-delivery incidents. Misrouted output to the wrong customer is both a PI1.4 failure and a confidentiality incident.
PI1.5: storage
- Controls: integrity checks on stored data (checksums, database constraints), retention and archiving of input, processing and output records for the period customers need them, protection of those records against alteration, and storage activity logs.
- Evidence: archive configuration, integrity check results, and access reviews over stored records. Destructive changes to stored data, whether by an attacker (MITRE ATT&CK T1565.001 Stored Data Manipulation) or a misbehaving automation, are the PI1.5 risk; see the Data Integrity Protection Against Destructive Attacks Guide.
Applying PI to payments, data pipelines and AI
| Use case | Key PI risks | Controls auditors look for |
|---|---|---|
| Payments and billing | Duplicate or missing transactions, wrong amounts, missed cut-offs | Idempotency keys, three-way reconciliation with processor and bank files, cut-off monitoring, maker-checker for manual adjustments |
| ETL and data pipelines | Silent row loss, schema drift, late data, wrong joins | Row counts and checksums per stage, schema contracts, freshness monitoring, quarantine tables, lineage records |
| AI and ML scoring | Model drift, data poisoning, unvalidated outputs, untracked model versions | Defined accuracy thresholds, evaluation before release, model and prompt version logging per output, drift monitoring, human review queues for low-confidence results |
| Agentic workflows | Agents taking actions outside specification, unreviewed writes to records | Action allow lists, approval gates for writes, logging of tool calls with inputs and outputs, reconciliation of agent changes |
- Payments: map PI controls to PCI DSS and SOX evidence to avoid collecting it twice. See the PCI DSS 4.0 Guide and AI Agents and SOX Controls.
- Pipelines: the ETL and ELT Pipeline Security Guide covers the security side; PI adds the completeness and accuracy checks between stages.
- AI: state accuracy as a specification (for example, a minimum precision on a held-out set, or a human review rate) so PI1.1 has something testable, and log the model and prompt version that produced each output so PI1.3 and PI1.4 can be traced. Training data integrity matters: see the AI Data Poisoning and Backdoors Guide and the AI Hallucination Business Risk Guide.
Where identity fits
Processing is done by non-human identities: batch job accounts, pipeline service principals, integration tokens and AI agents. Each can write to inputs, processing state and outputs. A job account with delete rights on the production database, or an agent with an over-privileged token, can corrupt or destroy the records PI1.5 asks you to protect; the PocketOS database deletion shows an AI coding agent wiping production with one over-scoped token. Give each job and agent its own identity scoped to the stages it runs, separate write access to archived records from processing roles, and log every write with the identity that made it so exceptions can be traced. See the SOC 2 CC6 Logical Access Guide.
Decision guidance
- Automated or manual reconciliation: manual sign-off on a daily spreadsheet is acceptable evidence at low volume, but it fails quietly when the reviewer is away. Above a few thousand transactions a day, automate the comparison and keep human review for breaks only.
- Reject or quarantine invalid input: rejecting at the API gives the sender immediate feedback and keeps bad data out; quarantining suits batch files where partial processing is acceptable. Either way, record every rejected item with a reason so PI1.2 can be sampled.
- Customer-facing or internal specifications: publish what customers need to submit correct input and interpret output; keep internal processing rules version-controlled but private. The auditor needs both.
- Small versus large organisations: a start-up with one billing flow can meet PI with schema validation, a daily automated reconciliation, an exception queue and a documented calculation specification. A large provider with many products needs per-flow owners, central monitoring of reconciliation breaks and a data quality function that reports to management.
- Subservice providers: if a payment processor or data platform performs part of the processing, carve it out, list the complementary controls you expect of it, and reconcile its output against yours.
How to implement
- Decide scope. Name the services and processing flows customers rely on for output, and leave out the rest. Narrow scope makes PI achievable.
- Write specifications. Inputs, processing rules, outputs and timeliness commitments per flow, version-controlled and published where customers need them.
- Map control points. For each flow mark where completeness and accuracy are checked: ingestion, each processing stage, release of output and storage.
- Automate checks and exception queues. Prefer automated reconciliations with alerting over manual review; give every queue an owner and an ageing target.
- Test before the period. Replay a sample of historic batches and trace them through inputs, processing and outputs; fix gaps while they are cheap. See the SOC 2 Readiness Checklist.
- Type 1, then Type 2. Confirm design first; retain dated evidence from day one of the period.
- Roll back safely. For any change to processing logic, keep the previous version deployable and re-run affected batches from retained inputs (PI1.5), with reconciliation of corrected output.
Detection and measurement
- Monitor: input rejection rate spikes, reconciliation breaks, exception queue ageing, late or missed jobs, output delivery failures, schema changes, model accuracy and drift metrics, and unexpected writes or deletes by processing identities (T1565 Data Manipulation covers the adversarial version).
| Metric | Why it matters |
|---|---|
| Reconciliation breaks per period and mean time to resolve | Core PI1.3 and PI1.4 evidence |
| Input rejection rate by source | PI1.2 effectiveness and upstream quality |
| Exception queue items older than target | Shows errors are corrected, not parked |
| Jobs completed within committed processing windows | Timeliness commitment |
| Outputs reissued due to errors | Direct measure of accuracy failures reaching customers |
| Model outputs within defined accuracy threshold, and human review rate | PI applied to AI processing |
Framework mapping
| Criterion | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| PI1.1 | SA-8 Security and Privacy Engineering Principles | PR.PS-01 | A.8.26 Application security requirements |
| PI1.2 | SI-10 Information Input Validation | PR.DS-02 | A.8.26, A.8.28 Secure coding |
| PI1.3 | SI-7 Software, Firmware, and Information Integrity; SI-11 Error Handling | PR.DS-10, DE.CM-09 | A.8.29 Security testing in development and acceptance, A.8.32 Change management |
| PI1.4 | AU-10 Non-repudiation; SI-7 | PR.DS-02 | A.5.14 Information transfer |
| PI1.5 | SI-7; SI-12 Information Management and Retention | PR.DS-01 | A.5.33 Protection of records, A.8.13 Information backup |
For the full cross-walk see the SOC 2 to ISO 27001 Mapping Guide.
Common failure patterns
- No written specifications: processing rules live only in code, so the auditor cannot test accuracy and PI1.1 fails first.
- Reconciliations that nobody reviews: reports run daily but breaks are not tracked to resolution, leaving no PI1.3 evidence.
- Scope too wide: every product added to PI, including those with no customer-relied-on output, multiplying evidence for no benefit.
- Exactness promised for AI output: commitments imply deterministic accuracy that a model cannot meet, producing exceptions every period.
- Processing identities with destructive rights: one job or agent credential can delete the inputs and archives needed to re-run and correct output.
- Manual fixes outside change control: engineers correct data directly in production during incidents without tickets, approvals or reconciliation of the fix.
Practitioner checklist
- In-scope processing flows named, with the reason customers rely on their output.
- Version-controlled specifications for inputs, processing rules, outputs and timeliness.
- Input validation, quarantine and duplicate detection at every ingestion point.
- Automated reconciliations between stages with owned exception queues and ageing targets.
- Output reconciled before release and delivered only to authorised recipients, with delivery logs.
- Inputs, processing records and outputs retained and protected long enough to re-run and correct.
- AI outputs measured against defined accuracy thresholds with model and prompt versions logged.
- Processing identities scoped per stage, without delete rights on archives.
- Data fixes in production made through change control and reconciled.
Standards and references
- AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
- AICPA: Proposed update of SOC 2 Trust Services Criteria
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Data Manipulation
- Cloudaware: SOC 2 criteria and points of focus reference
Related NHI Mgmt Group resources: SOC 2 Guide · SOC 2 Privacy Criteria Guide · SOC 2 Availability Criteria Guide · SOC 2 CC7 System Operations Guide. This guide summarises the AICPA SOC 2 processing integrity criteria and is not legal advice.