The Processing Integrity criterion
The Processing Integrity criterion requires that system processing is complete, valid, accurate, timely, and authorized. It ensures that the data processed by a system results in outputs that are consistent with intended business specifications and goals.
What it means
Processing Integrity focuses on the "correctness" of a transaction from start to finish. While the Security criterion focuses on who can access a system, Processing Integrity focuses on what happens to the data once it is inside. It ensures that calculations are performed correctly, no data is lost or corrupted during processing, and results are delivered within expected timeframes.
In practice, this means implementing controls at three stages: input (preventing "garbage in"), processing (ensuring logic works as intended), and output (verifying the result). This criterion is particularly critical for organizations providing services where a calculation error or missed transaction would lead to significant financial or operational failure for the client.
How to meet it
- Implement automated input validation (e.g., data type checks, range limits, and mandatory fields) to ensure only valid data enters the system.
- Establish automated error handling and alerting mechanisms to notify administrators when a process fails or produces an unexpected result.
- Perform regular reconciliations—such as comparing total records received versus total records processed—to ensure completeness.
- Use checksums, hashes, or parity bits to detect and prevent data corruption during transmission or storage.
- Create rigorous User Acceptance Testing (UAT) protocols that specifically test "edge cases" and boundary conditions for all processing logic.
- Implement monitoring tools to track the timeliness of processes against defined Service Level Agreements (SLAs).
Evidence an auditor asks for
- Functional requirement documents or system specifications that define exactly how data should be processed.
- UAT sign-offs and test scripts demonstrating that processing logic was verified before being deployed to production.
- Error logs and corresponding tickets showing that failed transactions were identified, investigated, and remediated.
- Reconciliation reports (e.g., daily balance checks or record counts) signed off by a reviewer to prove completeness.
Common pitfalls
- Confusing Security with Processing Integrity; for example, assuming that because data is encrypted (Security), the calculation performed on it must be accurate (Processing Integrity).
- Lack of documentation for manual interventions, such as an engineer manually updating a database record to "fix" a stuck transaction without a change ticket.
- Testing only the "happy path," failing to provide evidence that the system handles invalid inputs or unexpected interruptions gracefully.