Skip to main content
Control Institute
Category: Trust Services Criteria

Processing Integrity Criteria (PI1)

Also known as: PI1, Processing Integrity, PI Criteria, Processing Integrity Trust Services Criteria
Simply put

Processing Integrity is one of the optional categories within the SOC 2 Trust Services Criteria, focused on whether a system processes data in a way that is accurate, complete, timely, and authorized. It is most relevant to service organizations that process, run analytics on, or otherwise manipulate data on behalf of their customers. Because it is optional, an organization includes it in a SOC 2 examination only when it fits the defined scope.

Formal definition

The Processing Integrity category (referenced as PI1) is one of the four optional Trust Services Criteria categories that a service organization may add to the required Security (Common Criteria) category during a SOC 2 examination, depending on scope. It addresses whether system processing is complete, valid, accurate, timely, and authorized in meeting the entity's processing objectives and commitments. Available sources describe PI1 criteria spanning processing objectives, inputs, processing activities, outputs, and storage, with individual criteria such as PI1.1 addressing defined processing requirements and procedures to prevent, or detect and correct, processing errors; however, the exact number and wording of criteria depend on the applicable edition of the AICPA Trust Services Criteria and should be verified against the authoritative source. As with SOC 2 generally, an examination covering Processing Integrity results in an attestation report (not a certification) and attests only to the controls and period covered, not to freedom from all processing errors or breaches.

Why it matters

Processing Integrity matters most to service organizations whose core function involves processing, running analytics on, or otherwise manipulating data on behalf of their customers. For these organizations, a customer's trust hinges not just on whether data is kept secure, but on whether the system produces accurate, complete, timely, and authorized results. A payroll processor, a transaction settlement platform, or an analytics provider that silently miscalculates, drops records, or processes data out of sequence can cause significant downstream harm to its customers even when no security breach has occurred. Including Processing Integrity in a SOC 2 examination signals to customers that the organization has controls addressing these processing outcomes.

Because Processing Integrity is an optional category, organizations typically add it only when it fits their defined scope and speaks to the commitments they make to customers. A pure infrastructure or hosting provider may reasonably omit it, while a data-processing service may find that customers expect it. Selecting the category should follow from what the organization actually does and what it promises, rather than from a desire for a more comprehensive-looking report.

It is important to keep the boundaries of this assurance in mind. A SOC 2 examination covering Processing Integrity results in an attestation report, not a certification, and it attests only to the controls and the period covered. It does not guarantee that a system is free from all processing errors, nor does it substitute for the required Security (Common Criteria) category, which must be present in every SOC 2 examination. Processing Integrity supplements Security; it does not replace it.

Who it's relevant to

Data processing and analytics providers
Organizations that process, run analytics on, or otherwise manipulate data on behalf of their customers are the primary audience for Processing Integrity. For these services, customers often care whether outputs are accurate, complete, timely, and authorized, and adding PI1 to a SOC 2 examination lets the organization address those expectations directly.
Compliance and GRC managers
Those who scope SOC 2 examinations must decide whether Processing Integrity fits the organization's commitments and the defined scope. Since the category is optional, they weigh whether the organization's processing activities warrant its inclusion rather than adding it by default, and they align the controls documentation to the applicable edition of the Trust Services Criteria.
Auditors and CPA firms
The licensed CPA firms performing the SOC 2 examination assess the design, and in a Type II engagement the operating effectiveness, of the Processing Integrity controls over the defined period. They verify the specific PI1 criteria against the authoritative AICPA source, since the number and wording depend on the edition in force.
Customers and prospects evaluating a service
Organizations reviewing a vendor's SOC 2 report can use the Processing Integrity coverage to understand whether the vendor has controls addressing accurate, complete, timely, and authorized processing. They should note that the report attests only to the controls and period covered and does not guarantee freedom from all processing errors.

Inside PI1

Trust Services Criteria Category
Processing Integrity is one of the optional Trust Services Criteria categories in a SOC 2 examination. It is selected based on scoping decisions and is not required; only the Security category (Common Criteria) is required in every SOC 2 engagement.
Focus on System Processing
Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives. It concerns the integrity of processing itself rather than the confidentiality or availability of data.
PI Series Points of Focus
The PI1 criteria are supported by points of focus that describe considerations such as input completeness and accuracy, processing accuracy, and output completeness and accuracy. Points of focus are illustrative considerations that help evaluate the criteria rather than a mandatory checklist.
Relationship to the Common Criteria
Because Security (the Common Criteria) is always in scope, Processing Integrity is evaluated in addition to, and alongside, the Common Criteria when it is selected. The two are distinct categories addressing different aspects of the system.
Assessment Under Type I or Type II
As with other Trust Services Criteria, controls supporting Processing Integrity may be assessed for suitability of design at a point in time (Type I) or for both design and operating effectiveness over a defined review period (Type II), depending on the engagement scope.

Common questions

Answers to the questions practitioners most commonly ask about PI1.

Is Processing Integrity a required part of every SOC 2 report?
No. Security (the Common Criteria) is the only required category in a SOC 2 examination. Processing Integrity, along with Availability, Confidentiality, and Privacy, is optional and included only when the scope of the engagement calls for it. In most engagements, Processing Integrity is selected when the service organization's system processes transactions or data in a way that its user entities depend on for completeness, accuracy, timeliness, and authorization. Whether it belongs in scope is a scoping decision made based on the services provided and the needs of report users.
Does meeting the Processing Integrity Criteria mean the system's outputs are always correct?
Not exactly. Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives. It does not guarantee that data was correct before it entered the system, nor does it certify the underlying business logic. A SOC 2 report incorporating Processing Integrity attests only to the controls covered and, for a Type II, over the defined review period; it does not guarantee error-free results in all circumstances or freedom from issues outside the tested controls and period.
How does Processing Integrity relate to the Common Criteria in a SOC 2 examination?
When Processing Integrity is in scope, its criteria are evaluated in addition to the Security Common Criteria rather than in place of them. The Common Criteria remain applicable regardless of which optional categories are selected. In practice, the Processing Integrity criteria focus on the processing lifecycle, while the Common Criteria address the broader control environment, and both sets are assessed together in the engagement.
What kinds of controls typically support the Processing Integrity Criteria?
The specific controls depend on the service organization, its system, and the scope agreed with the CPA firm. In most engagements, organizations point to controls that address the completeness, accuracy, and validity of inputs, processing, and outputs, along with authorization and timeliness. Whether any particular control is appropriate is determined during scoping and evaluation rather than dictated as universally mandatory, since suitability varies by system and by the auditor's judgment.
How should an organization decide whether to include Processing Integrity in scope?
This is a scoping decision typically driven by whether report users rely on the service organization to process their transactions or data accurately and completely. Organizations that provide transaction processing, calculation, or data-handling services often find it relevant, while others may not. The decision is generally made together with the CPA firm and reflects the services provided and the objectives the report is intended to support, so it varies from one engagement to another.
What is the difference between assessing Processing Integrity in a Type I versus a Type II report?
In a Type I report, the Processing Integrity criteria are evaluated for suitability of design at a point in time. In a Type II report, they are evaluated for both design and operating effectiveness over a defined review period, the length of which is set by scoping decisions rather than fixed. This means a Type II provides evidence that processing controls operated over time, whereas a Type I speaks only to how they were designed as of a specified date.

Common misconceptions

Processing Integrity is a required part of every SOC 2 report.
Processing Integrity is an optional Trust Services Criteria category selected based on scope. Only the Security category (Common Criteria) is required in a SOC 2 examination; Availability, Processing Integrity, Confidentiality, and Privacy are included only when in scope.
Processing Integrity means the data itself is accurate or free from error.
Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized in meeting the entity's objectives. It concerns the integrity of the processing rather than guaranteeing the underlying business data is correct, and a SOC 2 report attests only to the controls and period covered.
Processing Integrity in SOC 2 corresponds directly to a specific ISO 27001 Annex A control set.
The Trust Services Criteria are distinct from ISO 27001 Annex A reference controls. Mapping between SOC 2 and ISO 27001 is possible but partial, and satisfying Processing Integrity does not automatically satisfy any ISO 27001 requirement.

Best practices

Confirm during scoping whether Processing Integrity is relevant to the services being examined, since it is optional and typically included only where completeness, validity, accuracy, timeliness, and authorization of processing matter to user entities.
Use the PI series points of focus as considerations to guide control identification, treating them as illustrative rather than a mandatory checklist that must be satisfied item by item.
Define controls that address input, processing, and output stages so that completeness and accuracy can be evidenced across the processing lifecycle.
Clarify to report users that Processing Integrity attests only to the controls and the period covered and does not guarantee that all business data is error-free or that no processing issues will ever occur.
Coordinate Processing Integrity controls with the Security (Common Criteria) controls, since Security is always in scope and both categories may be assessed together.
If pursuing both SOC 2 and ISO 27001, avoid assuming equivalence; document any mapping as partial and validate each framework's requirements separately rather than relying on one outcome to satisfy the other.