System inputs are controlled to result in products, services, and reporting that are complete and accurate.
Also written as PI 1.2, TSC PI1.2, SOC2 PI1.2, SOC 2 Type 2 PI1.2.
Input completeness and accuracy is one of 5 criteria in the Processing Integrity (PI1) series of the Processing Integrity category. System inputs are controlled to result in products, services, and reporting that are complete and accurate. Because this sits outside the Common Criteria, it is only tested when Processing Integrity is in the scope of your engagement — check your report scope before building evidence for it.
When preparing for a SOC 2 audit against PI1.2, gather artefacts such as:
PI1.2 has no clean one-to-one ISO 27001:2022 Annex A equivalent — it is largely a governance or reporting expectation that ISO 27001 handles through the management-system clauses (4–10) rather than an Annex A control. Treat it as its own requirement rather than assuming ISMS evidence covers it.
All PI1 Processing Integrity criteria →
Only if the Processing Integrity category is in scope. The Common Criteria (CC1–CC9) are mandatory for every SOC 2, but PI1 criteria are tested only when you elect to include Processing Integrity in the engagement. Scope is your choice, usually driven by customer contracts.
In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet PI1.2 if it operated. In a Type 2 report they also test operating effectiveness by sampling evidence from across the review period, typically 3 to 12 months. That difference is why Type 2 evidence has to be continuous rather than assembled the week before fieldwork.
A control that fails becomes an exception, which the auditor describes in the report along with management's response. Exceptions do not automatically make a report "failed" — a SOC 2 report is an opinion, not a pass/fail certificate — but a qualified opinion is what customers notice, so remediate and re-test before fieldwork closes where you can.