SOC 2 PI1.5: Processing Integrity - Storage Inputs and Outputs Completely and Accurately

Set up database integrity controls: referential integrity constraints, data type enforcement, check constraints for valid ranges, ACID transaction management, and automated integrity checks. Use triggers or application logic to enforce business rules on stored data. These are your first line of defence against bad data persisting in your systems. For file storage, implement checksums to detect corruption, write verification for critical data, journaling filesystems to prevent partial write corruption, and object storage with built-in integrity verification (S3 ETags, Azure Blob checksums, etc.). Run periodic checksum comparisons against stored data to catch silent corruption. Enable change tracking and audit trails. Database audit logging should capture who changed what, when, and what the values were before and after. Use change data capture or triggers for critical tables. Store audit logs separately from the data they track so they cannot be tampered with alongside the data. Restrict who can modify stored data. Implement access controls at both the database and filesystem level. Limit direct database access to authorised administrators and application service accounts. Use application-layer authorisation to control which users can modify specific records. Monitor for unauthorised modification attempts. Build automated data integrity monitoring. Run scheduled checks verifying that critical data meets expected quality standards, compare checksums on stored files, watch for unexpected data changes, and alert on integrity violations. Do not wait for someone to report a problem. Have a clear process for when things go wrong. When corruption or unauthorised modification is detected, you need forensic investigation to determine cause and scope, recovery procedures to restore correct data from backups, root cause analysis to prevent recurrence, and a way to notify affected parties. Document every step.