SOC 2 PI1.1: Processing Integrity - Completeness, Accuracy, and Timeliness Objectives
What This Control Requires
The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product or service specifications, to support the use of products or services.
In Plain Language
You cannot verify that processing is correct if you have never defined what "correct" means. This control is about establishing that baseline: documenting exactly what your systems are supposed to do with data, what inputs they expect, what transformations they apply, and what outputs they produce.
For every critical system or service, you need clear specifications covering data quality requirements, processing logic, and timeliness objectives. These specifications need to be communicated to both your internal teams and your customers. If marketing promises one thing and the system does another, that is a processing integrity problem.
Auditors use these specifications as the yardstick for everything else in processing integrity. If the specifications do not exist or are vague, there is no way to assess whether processing integrity is maintained - and that is an automatic finding.
How to Implement
Document processing specifications for every critical system and service. For each one, define the expected inputs (data formats, validation rules, acceptable ranges), the processing logic (transformations, calculations, business rules), the expected outputs (formats, delivery mechanisms, quality standards), and timeliness requirements (processing windows, SLAs, maximum acceptable latency).
Define data quality dimensions and what they mean for each type of data you process. Spell out what completeness, accuracy, validity, consistency, and timeliness look like in concrete, testable terms. Create validation rules: required fields must not be null, financial calculations must balance, dates must fall within valid ranges, cross-system data must reconcile.
Share these specifications with the people who need them. Give internal teams the full technical detail. Give customers clear product documentation, API documentation, and service descriptions that explain what processing is performed and what to expect. Make sure marketing materials actually reflect what your systems do.
Implement input validation that enforces your quality requirements at the point of data entry or receipt. This includes field-level checks (type, format, range), record-level checks (required fields, business rule compliance), and batch-level checks (expected record counts, control totals, header/trailer validation).
Maintain system documentation that traces the processing flow from input to output. Data flow diagrams, process maps, and technical specifications all work. The critical part is keeping them current when processing logic changes - stale documentation is worse than no documentation because it creates false confidence.
Track processing quality metrics: error rates, rejection rates, processing timeliness, data quality scores. Report them to management and use them to spot problems before customers do.
Evidence Your Auditor Will Request
- Processing specifications for critical systems including input, processing, and output definitions
- Data quality requirements documentation with validation rules and quality dimensions
- Service level objectives for processing timeliness and completeness
- Customer-facing documentation describing processing capabilities and data quality standards
- Processing quality metrics and reports showing measurement of completeness, accuracy, and timeliness
Common Mistakes
- Processing specifications are not documented, relying on institutional knowledge of how systems work
- Data quality requirements are not formally defined, making it impossible to assess processing accuracy
- Service level objectives for processing timeliness are not established or communicated
- Customer documentation does not accurately reflect actual system processing capabilities
- No metrics are tracked for processing quality, preventing identification of processing integrity issues
Related Controls Across Frameworks
Frequently Asked Questions
How detailed should processing specifications be?
Who is responsible for defining processing integrity requirements?
How do processing integrity requirements differ from security requirements?
Track SOC 2 compliance in one place
AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.
Start Free Assessment