SOC 2 PI1.3: processing controls, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For PI1.3, the usual records are these.

• Job monitoring and failure alerts
• Reconciliation reports
• Exception tickets with resolutions

What Polara asks about it

The free readiness assessment asks 3 questions that bear on PI1.3. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• Do you check that each processing run is complete and accurate, for example by reconciling counts or totals between input and output? If yes, show it: reconciliation report comparing input and output counts or totals, a job summary with record counts, or an automated check result from the processing pipeline. If no, the fix: add a reconciliation of record counts or totals between input and output to each processing run and keep its result.
• When processing fails or produces a wrong result, is the error logged, assigned to someone, corrected and the work run again? If yes, show it: alert for a failed job, an error ticket showing the correction and the successful re-run, or an error queue with its resolution history. If no, the fix: route each failed or wrong processing run to a ticket with an owner, and close it only when the corrected run completes.
• Do you keep records of inputs, processing runs and outputs long enough to trace any result back to its source? If yes, show it: log retention configuration, a job history export, an import or delivery log, or an audit table showing each run with its inputs and outputs. If no, the fix: keep job, import and delivery logs for a set period, protect them from change, and say where they are kept.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Processing Integrity Policy covers PI1.3.

Is it in your scope?

Only if you add Processing Integrity. Whether the system processes data completely, accurately and on time. Inputs, processing, outputs and stored records. It fits a product whose customers depend on its calculations or transactions being right.

The scoping tool decides it with one question: Add it when customers rely on your processing being complete and accurate, such as payments, payroll, invoices or calculations they act on. Defined inputs, completeness and accuracy checks, error handling, output delivery and the records that trace a result to its source.

Security is the default and always in scope. Adding Processing Integrity in the assessment puts its 5 criteria into the report and the examination, and adds 7 questions to the assessment.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Processing integrity: the criteria around it

PI1.3 is one of 5 criteria in processing integrity, PI1.1 to PI1.5. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• PI1.1, processing specifications
• PI1.2, input controls
• PI1.3, this page
• PI1.4, output controls
• PI1.5, stored data integrity

Before it: PI1.2, input controls. After it: PI1.4, output controls. All the criteria, Security first, are on the Trust Services Criteria page, grouped by category.