PI1.2 PI1 · Processing Integrity · Processing Integrity

PI1.2 — Input completeness and accuracy

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.

What SOC 2 PI1.2 requires

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.

Audit evidence assessors look for

When preparing for a SOC 2 audit against PI1.2, gather artefacts such as:

  • Input validation and edit-check configuration
  • Rejected / error input handling procedures and logs
  • Reconciliations of inputs received vs. processed
  • Source data authorization records

ISO 27001 mapping

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.

Map PI1.2 to ISO 27001 & NIST CSF →
Crosswalk this criterion in the Control Mapper & Gap Assessment.
Document the risk →
Record treatment for gaps against PI1.2 in the Risk Register.

Other Processing Integrity criteria

PI1.1 Processing objectives and specifications PI1.3 Processing completeness, accuracy and timeliness PI1.4 Output completeness, accuracy and distribution PI1.5 Storage of inputs, items in processing and outputs

All PI1 Processing Integrity criteria →

Frequently asked questions

Is PI1.2 required for a SOC 2 report?

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.

How does an auditor test PI1.2?

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.

What happens if PI1.2 fails testing?

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.