Processing Integrity: did the system do the sum right?

Complete

Every item that should be processed is processed, once, with nothing dropped or doubled.

Valid

Only genuine transactions go through; junk and duplicates are stopped.

Accurate

Results are correct: the right amounts, rates, rounding and records.

Timely

Processing happens within the time you committed to.

Authorized

Processing happens only as approved, and nobody can quietly alter it.

Processing Integrity is not data quality in general. It tests whether your system processes what it receives as specified. Garbage sent in by a customer is usually a matter for CUECs.

If your outputs feed a customer's financial statements, the customer's auditor may want a SOC 1 instead of, or as well as, a SOC 2 with Processing Integrity. The two answer different readers.

1. PI1.1
   Definitions and specificationsYou produce and share clear information about what the system processes and what each output means. Example: a published data dictionary and API specification.
2. PI1.2
   InputsInputs are checked for completeness and accuracy. Example: validation rules, duplicate detection and batch control totals at intake.
3. PI1.3
   ProcessingProcessing produces the intended result. Example: automated tests on calculation logic and an exceptions queue for failed jobs.
4. PI1.4
   OutputsOutputs are delivered complete, accurate and on time, as specified. Example: output-to-input reconciliation before files are released.
5. PI1.5
   StorageInputs, work in progress and outputs are stored completely and accurately. Example: database integrity checks and restricted write access to stored results.

What a good data definition covers (PI1.1)

• Which events or records the data includes, and which it leaves out.
• What each field means, its source and its unit.
• How precise each value is, and any uncertainty in it.
• The date or period the data relates to.

• Specifications. The documented definitions and processing rules in force during the period.
• Input edits. Validation configuration, and examples of rejected inputs and how they were handled.
• Reconciliations. Signed or system-stamped reconciliations for sampled days, with breaks investigated.
• Error queue. The log of failed or suspended items, their age, and who cleared them.
• Logic changes. Change tickets for calculation rules, with test results, under CC8.1.

• Reconciliations done in someone's head. If nobody records the check, the auditor cannot sample it.
• Breaks found, never resolved. A reconciliation that flags a difference and closes without explanation is a deviation in waiting.
• Silent retries. Jobs that retry until they succeed can hide duplicates or skipped items.
• Specifications that drifted. The documented rules describe last year's product.
• Adding it with no customer reliance. Five more criteria to evidence each year, for a promise nobody asked you to make.

• OverviewTrust Services CriteriaThe five categories, with CC1 to CC9 read as questions your controls answer.
• SecurityThe Security category, criterion by criterionCC1 to CC9 in plain words, with the evidence each invites.
• AvailabilityThe Availability categoryA1.1 to A1.3: capacity, protection and tested recovery.
• ConfidentialityThe Confidentiality categoryC1.1 and C1.2: identifying, protecting and disposing of confidential data.
• PrivacyThe Privacy categoryP1 to P8: notice, choice, collection, use, access, disclosure, quality, monitoring.

Sources: AICPA, TSP section 100, 2017 Trust Services Criteria (revised points of focus), processing integrity category definition and criteria PI1.1 to PI1.5; AICPA AT-C section 320 for the SOC 1 contrast. Examples are illustrative.