Skip to main content
Control Institute
Category: Trust Services Criteria

Processing Integrity

Also known as: Processing Integrity Criteria, PI
Simply put

Processing Integrity is one of the optional categories a company can include in a SOC 2 examination. It focuses on whether a system processes information the way it is supposed to, so that data is complete, accurate, timely, and authorized as it moves through the system. It is not required in every SOC 2 engagement and is typically selected when the reliability of data processing is important to the service being provided.

Formal definition

Processing Integrity is one of the optional Trust Services Criteria categories within a SOC 2 examination, selected based on scope alongside the required Security (Common Criteria) category, and is distinct from Availability, Confidentiality, and Privacy. It addresses whether system processing is complete, valid, accurate, timely, and authorized throughout the information lifecycle, from acceptance of inputs from authorized sources through processing, storage, maintenance, and output. In practice, controls supporting Processing Integrity are evaluated across processing objectives, inputs, and outputs to detect and address processing errors. As with all Trust Services Criteria, a SOC 2 report addressing Processing Integrity attests only to the controls and the period or point in time covered by the engagement and does not, on its own, guarantee error-free processing outside that defined scope. Note that the Trust Services Criteria are separate from ISO 27001 Annex A reference controls; satisfying Processing Integrity in SOC 2 does not automatically satisfy ISO 27001 requirements.

Why it matters

Processing Integrity addresses a question that Security alone does not: even when a system is well protected against unauthorized access, its outputs may still be wrong if inputs are incomplete, transformations introduce errors, or processing occurs at the wrong time. For services where the correctness of computed results directly affects customer decisions or obligations, such as transaction processing, billing, data transformation, or analytics platforms, the reliability of data as it moves through the system can be as important as its confidentiality. Including Processing Integrity in a SOC 2 examination signals to customers and their auditors that the service organization has controls designed to keep processing complete, valid, accurate, timely, and authorized throughout the information lifecycle.

Because Processing Integrity is an optional Trust Services Criteria category rather than a required one, its presence in a report reflects a deliberate scoping decision, typically made when data processing reliability is central to the service being provided. Its absence does not indicate a deficiency; it simply means the engagement did not cover that dimension. Readers of a SOC 2 report should therefore check which categories were in scope before drawing conclusions about processing reliability.

It is important to understand the limits of what Processing Integrity attests to. A SOC 2 report addressing this category speaks only to the controls and the period or point in time covered by the engagement, and does not on its own guarantee error-free processing outside that defined scope. It is also distinct from ISO 27001 Annex A reference controls, so satisfying Processing Integrity within a SOC 2 examination does not automatically satisfy ISO 27001 requirements.

Who it's relevant to

Compliance and GRC Managers
Those responsible for scoping a SOC 2 examination must decide whether Processing Integrity belongs in scope. It is typically selected when the reliability of data processing is important to the service being provided, and its inclusion should follow from how central processing correctness is to customer commitments rather than being added by default.
Service Organizations Handling Transactional or Computed Data
Organizations whose services depend on processing data correctly, such as those performing calculations, transformations, or transaction handling, are the most common candidates for including Processing Integrity, since customers of these services rely on complete, accurate, timely, and authorized outputs.
Auditors and CPA Firms
The licensed CPA firm performing the SOC 2 examination evaluates controls supporting Processing Integrity across processing objectives, inputs, and outputs to determine whether they detect and address processing errors, within the scope and period defined for the engagement.
Customers and Report Readers
Those relying on a vendor's SOC 2 report should confirm whether Processing Integrity was in scope before assuming processing reliability has been assessed. They should also recognize that the report attests only to the controls and period covered and does not, on its own, guarantee error-free processing beyond that scope.

Inside Processing Integrity

Trust Services Category
Processing Integrity is one of the optional Trust Services Criteria categories in a SOC 2 examination. Unlike Security (the Common Criteria), which is required, Processing Integrity is selected based on scoping decisions when the completeness, validity, accuracy, timeliness, and authorization of system processing are relevant to the services being reported on.
Scope of System Processing
This category addresses whether a system achieves its objective by delivering the right data at the right price at the right time. It focuses on the processing performed by the system rather than on the correctness of the data inputs themselves, meaning it typically does not attest to the accuracy of information supplied by users or upstream sources.
Relationship to Security
Processing Integrity is evaluated alongside the required Security category and any other selected categories (Availability, Confidentiality, Privacy). It does not replace the Common Criteria; in most engagements it supplements Security where the reliability of transaction processing is material to user entities.
Applicable Report Type
Like other Trust Services Criteria, Processing Integrity can be assessed in a SOC 2 Type I (suitability of design at a point in time) or a Type II (design and operating effectiveness over a defined review period, the length of which is set by scoping decisions). The outcome is a report under the AICPA SSAE 18 standard, not a certification.

Common questions

Answers to the questions practitioners most commonly ask about Processing Integrity.

Is Processing Integrity a required part of every SOC 2 examination?
No. Security (the Common Criteria) is the only required Trust Services Criteria category. Processing Integrity is one of the four optional categories, alongside Availability, Confidentiality, and Privacy, and is included only when scoping decisions call for it. Many SOC 2 examinations do not include Processing Integrity at all.
Does Processing Integrity mean the data itself is accurate or correct?
Not exactly. Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized in relation to the entity's objectives. It focuses on the integrity of processing rather than guaranteeing that the underlying source data is itself correct. Data quality issues introduced before processing typically fall outside what this category attests to.
When would an organization choose to include Processing Integrity in its SOC 2 scope?
In most engagements, Processing Integrity is selected when the service involves transaction processing, calculations, or data transformations where completeness and accuracy of outputs are central to customer commitments, such as payroll, payments, or financial data processing. The decision depends on the nature of the service and the assurances customers require, and is made during scoping with the CPA firm.
What kinds of controls typically support Processing Integrity?
Depending on scope, supporting controls often include input validation, edit and reconciliation checks, error handling and exception reporting, processing authorization, and controls over the completeness and timeliness of outputs. The specific controls are determined by the entity's processing objectives and are evaluated by the auditor against the applicable criteria.
How is Processing Integrity evaluated differently in a Type I versus a Type II report?
A Type I report assesses the suitability of design of Processing Integrity controls at a point in time, while a Type II report assesses both design and operating effectiveness over a defined review period whose length is set by scoping decisions. In a Type II examination, the auditor tests whether the relevant controls operated effectively throughout the covered period.
Does including Processing Integrity in a SOC 2 report satisfy any ISO 27001 requirements?
Not automatically. Processing Integrity is a Trust Services Criteria category and should not be conflated with ISO 27001 Annex A reference controls or its clause 4-10 ISMS requirements. Mapping between the frameworks is possible but partial, and satisfying Processing Integrity criteria under SOC 2 does not by itself demonstrate conformance with ISO 27001.

Common misconceptions

Processing Integrity is a required part of every SOC 2 report.
Only the Security category (the Common Criteria) is required in a SOC 2 examination. Processing Integrity is optional and is included only when scoping decisions determine that the completeness, accuracy, timeliness, and authorization of processing are relevant to the service.
Processing Integrity guarantees that the data in a system is accurate.
The category typically addresses whether processing is complete, valid, accurate, timely, and authorized as performed by the system, not whether the underlying data entered into the system was itself correct. Errors originating in source data supplied by users or upstream systems are generally outside its scope.
Processing Integrity is equivalent to an ISO 27001 control set covering data quality.
The Trust Services Criteria are distinct from ISO 27001 Annex A reference controls, which are selected via a Statement of Applicability informed by risk assessment. Mapping between the two is possible but partial, and addressing Processing Integrity in a SOC 2 report does not automatically satisfy any ISO 27001 requirement.

Best practices

Confirm during scoping whether Processing Integrity is relevant to the service; include it only where the completeness, validity, accuracy, timeliness, and authorization of system processing matter to user entities, rather than adding it by default.
Clearly define the boundary between system processing and input data, and document in the report that the category typically addresses processing performed by the system rather than the accuracy of data supplied by users or upstream sources.
Design controls that evidence each dimension of processing integrity (completeness, validity, accuracy, timeliness, and authorization) so that, in a Type II engagement, operating effectiveness can be demonstrated over the defined review period.
Coordinate Processing Integrity with the required Security category and any other selected categories to avoid gaps, since it supplements rather than replaces the Common Criteria.
State the limitations plainly: a SOC 2 report attests only to the controls and the period covered and does not guarantee freedom from processing errors or breaches outside that scope.
If stakeholders expect alignment with ISO 27001, treat any mapping as partial and confirm requirements separately, because satisfying Processing Integrity does not automatically satisfy ISO 27001 clauses or Annex A controls.