SOC 2 PI1.2: input 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.2, the usual records are these.

• Input validation rules in code or configuration
• Logs of rejected inputs
• Tests covering input validation

What Polara asks about it

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

• Are the inputs your service accepts defined, with inputs that break those rules rejected or flagged? If yes, show it: API schema or import specification with required fields and ranges, validation code or configuration, or a log of rejected inputs with the reason for each. If no, the fix: write down the required fields, formats and allowed ranges for each input, enforce them with validation, and keep a record of rejected inputs.
• 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.2.

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.2 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, this page
• PI1.3, processing controls
• PI1.4, output controls
• PI1.5, stored data integrity

Before it: PI1.1, processing specifications. After it: PI1.3, processing controls. All the criteria, Security first, are on the Trust Services Criteria page, grouped by category.