SOC 2 Processing Integrity Criteria (PI1) Explained

Security is mandatory in every SOC 2. Optional Trust Services Criteria let you expand the report to match customer promises — Processing Integrity (PI1) is one of those expansions.

Only include Processing Integrity (PI1) if your system description and commercial claims truly require it; unused criteria create unnecessary audit surface.

Scope discipline: If sales decks promise processing outcomes, expect auditors to test related controls — align marketing with the report.

What Processing Integrity (PI1) emphasises

Processing integrity asks whether system processing is complete, valid, accurate, timely, and authorised. It fits financial workflows, transaction engines, and data pipelines with customer integrity promises.

Evidence patterns

Input validation and reconciliation jobs
Error queues and exception handling evidence
Job monitoring and integrity alerts
Change control on processing logic

When to include it

Include Processing Integrity (PI1) when customer contracts, SLAs, or product claims create an expectation auditors can test. Otherwise keep the report lean on Security (and Privacy if needed) only.

How CyberSilo Helps

Evidence mapping in CyberSilo CSA
Detection and logging proof with ThreatHawk SIEM
Advisory scoping — contact CyberSilo

Talk to CyberSilo

Map evidence and operations with CyberSilo CSA and ThreatHawk.

Talk to CyberSilo SOC 2 hub

Frequently Asked Questions

Is Processing Integrity (PI1) required for every SOC 2?

No — Security is required; other TSCs are optional based on scope.

Can we add it mid-Type II period?

Possible but disruptive — plan criteria before the examination window.

How does CSA help?

Maps controls and evidence tickets to the selected TSC set.

SOC 2 Processing Integrity Criteria (PI1) Explained

What Processing Integrity (PI1) emphasises

Evidence patterns

When to include it