SOC 2 Processing Integrity: Criteria, Controls & Guide

A system can be secure, highly available, and protected against unauthorized access and still give customers the wrong answer. For instance, consider a payment platform that processes the same transaction twice. Or an analytics application that drops a portion of its input data before generating a report. A payroll system could calculate salaries incorrectly, while a data platform could deliver an incomplete report despite having experienced no security incident. These are processing integrity problems.

Demonstrating that systems produce reliable results can be just as important as demonstrating that those systems are secure for organizations in the USA that process, transform, calculate, or analyze customer information.

This is where the SOC 2 Processing Integrity Criteria come into focus. Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized to meet an organization's objectives. The AICPA's current Trust Services Criteria reference is the 2017 TSC with revised Points of Focus issued in 2022.  But what do these criteria actually mean in practice, and what should organizations consider when preparing for a SOC 2 examination?

What Is SOC 2 Processing Integrity?

SOC 2 processing integrity focuses on whether a service organization’s systems process information as intended and consistently produce reliable results. The AICPA defines Processing Integrity around five characteristics: processing should be complete, valid, accurate, timely, and authorized to meet the organization’s objectives. This makes processing integrity broader than simply verifying whether an application produces an accurate result. It considers the complete processing lifecycle, from the information entering the system to how it is processed, stored, maintained, and ultimately delivered as an output.

A useful way to understand processing integrity SOC 2 requirements is to consider what could happen when controls fail at any stage. A SaaS platform may perform a financial calculation correctly, but its processing could still lack integrity if it receives incomplete information, processes an unauthorized transaction, loses data during processing, stores an incorrect result, or generates an incomplete customer report. For organizations in the USA, the SOC 2 Processing Integrity Criteria therefore provide a way to demonstrate that their services do more than remain secure and available, they process information completely, validly, accurately, and on time, while ensuring that processing activities are properly authorized.

Is Processing Integrity Required for SOC 2?

When considering SOC 2 processing integrity requirements, it is important to understand that Processing Integrity is one of the five Trust Services Criteria that can be included in a SOC 2 examination. These criteria cover Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the required criterion for every SOC 2 examination, while the other criteria are included based on the nature of the organization’s services, commitments, and objectives. Therefore, Processing Integrity is not automatically required for every SOC 2 engagement. It becomes particularly relevant when a service organization performs meaningful processing on behalf of its customers, such as transactions, calculations, data analysis, transformations, or automated decision-making.

For businesses in the USA, the decision to include Processing Integrity should be based on the potential impact of incorrect or incomplete processing on the services delivered to customers. A fintech platform processing financial transactions, a payroll provider calculating employee compensation, or an analytics SaaS platform generating business-critical reports may have a stronger need to address Processing Integrity than an organization primarily providing infrastructure or data storage. Rather than asking only, “Do we process data?”, organizations should ask, “Could an error, omission, delay, or unauthorized activity in our processing affect the service or results our customers receive?” If the answer is yes, including the processing integrity SOC 2 criteria may provide an important layer of assurance that the system consistently produces reliable results.

Demonstrate your commitment to security and strengthen your position with enterprise customers through SOC 2 assurance.

The 5 SOC 2 Processing Integrity Criteria Explained

SOC 2 Processing Integrity criteria evaluate whether a system processes information according to its defined objectives. PI1.1–PI1.5 cover the processing lifecycle, from defining objectives and validating inputs to processing, maintaining, and delivering information. Together, they assess whether processing is complete, valid, accurate, timely, and authorized, which is particularly important for organizations in the USA that handle business-critical transactions, calculations, reporting, or analytics.

PI1.1: Quality Information for Processing

PI1.1 establishes the foundation for processing integrity by focusing on whether the organization obtains, generates, uses, and communicates relevant information about its processing objectives. In simple terms, the organization needs to clearly understand what the system is supposed to do and what constitutes a correct result. This may involve documented processing requirements, system specifications, business rules, data definitions, product or service requirements, and expected outputs. For example, if a US-based analytics provider has not clearly defined how a customer metric should be calculated, it becomes difficult to determine whether the resulting calculation is accurate. Establishing clear processing objectives therefore provides the baseline against which the remaining processing integrity criteria SOC 2 controls can be evaluated.

PI1.2: System Inputs

Once processing objectives are defined, organizations need to ensure that the information entering the system is appropriate for the intended processing. PI1.2 focuses on controls over system inputs, including whether information is complete, accurate, and appropriately authorized. Depending on the system, this can involve input validation, required-field checks, data-format validation, duplicate detection, authorization checks, interface reconciliation, and exception handling. Consider a payroll platform expecting 20,000 employee records but receiving only 19,800. Without an effective mechanism to identify the discrepancy, the system could process incomplete information and produce unreliable results. SOC 2 processing integrity controls should therefore address not only whether a system accepts inputs, but also whether those inputs meet the requirements necessary for reliable processing.

PI1.3: System Processing

PI1.3 focuses on the processing activities performed by the system and whether they operate according to defined requirements and objectives. This can include controls such as automated validation, transaction reconciliation, processing logs, business-rule validation, error detection, exception monitoring, and controls over changes to processing logic. For example, an e-commerce platform may successfully accept thousands of transactions while still experiencing duplicate transactions, calculation errors, failed processing, or unauthorized processing activities. Effective controls should be capable of identifying and addressing these issues rather than treating successful system availability as evidence of successful processing. This is central to the SOC 2 processing integrity principle: a system needs to produce the intended result, not merely remain operational.

PI1.4: Data Storage and Maintenance

Processing integrity also extends beyond the point at which information is processed. PI1.4 considers how inputs, information in processing, and outputs are stored and maintained so that they remain complete, accurate, and timely in accordance with system requirements. Depending on the environment, organizations may rely on data integrity checks, reconciliation procedures, database controls, controlled data modifications, retention mechanisms, and backup validation. This is important because a system could initially produce a correct result but subsequently compromise that result through an unauthorized or uncontrolled modification. Maintaining the integrity of information throughout its lifecycle is therefore an important part of the SOC 2 processing integrity standards.

PI1.5: System Outputs

The final stage considers whether the information produced by the system is maintained and delivered in accordance with defined requirements. PI1.5 focuses on ensuring that outputs remain complete, accurate, and timely, making output validation an important part of the overall processing lifecycle. Relevant controls may include output reconciliation, report validation, completeness checks, accuracy reviews, distribution controls, delivery monitoring, and exception reporting. For example, a financial reporting platform could correctly process 100,000 transactions but generate a customer report containing only 99,500. Even though the underlying transactions were processed successfully, the incomplete output means the customer has not received the intended result. This demonstrates why the SOC 2 processing integrity criteria extend from the initial input all the way to the information ultimately delivered to the customer.

What Are SOC 2 Processing Integrity Controls?

A common misconception is that the SOC 2 processing integrity standards prescribe a fixed checklist of technologies or controls that every organization must implement. They do not. The Trust Services Criteria establish the outcomes an organization should achieve, while the specific controls are determined by the nature of its systems, processing activities, risks, and customer commitments. In practice, a SOC 2 processing integrity framework should therefore follow the complete processing lifecycle: how information enters the system, how it is processed, how it is stored and maintained, and how the resulting information is delivered to customers.

This risk-based approach is particularly important because processing environments can vary significantly between service providers. An organization may use input validation and automated reconciliation to prevent incomplete transactions, processing logs and exception monitoring to identify errors, data integrity checks to protect stored information, and output validation to ensure customers receive accurate results. Ongoing monitoring, alerts, and corrective actions can then help identify and address processing issues as they occur. The objective is not to implement every possible control, but to establish controls that are appropriate to the organization’s processing risks and demonstrate that its systems consistently produce the intended results.

What Evidence Might an Auditor Examine?

Meeting the SOC 2 processing integrity criteria involves more than having policies and procedures documented. An organization needs to demonstrate that the controls addressing its processing activities are appropriately designed and, where applicable, operating effectively. The evidence an auditor examines will depend on the organization’s systems, services, and control environment, but may include processing specifications, data-flow documentation, input validation records, processing logs, reconciliation reports, exception reports, error-resolution records, output validation, system-generated audit trails, change-management records, monitoring records, and evidence of management review.

The nature of the SOC 2 examination also matters. In a SOC 2 Type 1 examination, the focus is on whether controls are suitably designed and implemented as of a specified date. A SOC 2 Type 2 examination goes further by evaluating whether relevant controls operated effectively over a defined period. This means an organization cannot rely solely on having a well-designed reconciliation or validation process. It should be able to produce consistent, reliable evidence showing that the control was actually performed, exceptions were addressed, and issues were appropriately resolved throughout the examination period.

How to Prepare for SOC 2 Processing Integrity?

Preparing for the SOC 2 processing integrity criteria requirements is more effective when organizations approach the assessment as a review of the entire processing lifecycle rather than a last-minute compliance exercise. The objective is to understand how information moves through the system, where processing risks can occur, and whether existing controls provide sufficient assurance that the intended results will be produced. For organizations in the USA, the following steps can provide a practical starting point for evaluating Processing Integrity.

Map the Processing Lifecycle

Start by documenting how information enters the system, moves through different processing activities, is stored or maintained, and ultimately reaches the customer as an output. Mapping this flow helps identify where information could be lost, duplicated, altered, delayed, or processed incorrectly. It also provides a clearer basis for determining which controls are relevant to each stage.

Define Processing Objectives

Clearly establish what successful processing means for the service. This includes defining expectations around completeness, validity, accuracy, timeliness, and authorization. Without clearly defined processing objectives, it becomes difficult to determine whether a system is actually producing the results it is expected to deliver.

Identify Processing Risks

Evaluate where processing could fail or produce unreliable results. Risks may include incomplete inputs, duplicate transactions, incorrect calculations, unauthorized changes, processing delays, data corruption, or incomplete outputs. The assessment should consider both automated processes and situations where employees can manually intervene or override system processing.

Map Controls to the Criteria

Once the risks are understood, map existing SOC 2 processing integrity controls to the applicable PI1.1 through PI1.5 criteria. This helps organizations determine whether their current controls address the relevant risks and whether any gaps exist. The goal is not to implement controls simply because they appear on a checklist, but to establish controls that are appropriate to the organization's systems and processing objectives.

Identify and Organize Evidence

For each relevant control, determine what evidence demonstrates that it is appropriately designed and operating as intended. This could include processing logs, reconciliation records, validation results, exception reports, change records, or monitoring evidence. Establishing this evidence trail early can make the examination process more organized and reduce the risk of discovering documentation gaps later.

Review Exceptions, Not Just Successful Processing

A strong evaluation should look beyond routine, successful transactions. Review rejected inputs, failed transactions, processing errors, manual overrides, corrections, and unusual events to understand how the organization detects and responds to processing problems. This can reveal weaknesses that may not be visible when reviewing only normal processing activity.

Make Processing Integrity an Ongoing Practice

Processing Integrity should not become a project that receives attention only before a SOC 2 examination. Organizations should continuously monitor processing activities, review exceptions, evaluate changes to processing logic, and address identified issues. Treating Processing Integrity as part of ongoing operational governance helps organizations maintain reliable processing as systems, customer requirements, and business processes evolve.

Why Processing Integrity Matters for Business Trust?

SOC 2 Processing Integrity is ultimately about more than preventing errors. It is about demonstrating that the systems customers depend on consistently process information as intended and deliver results that are complete, valid, accurate, timely, and authorized. From validating inputs and controlling processing activities to maintaining data integrity and verifying outputs, each stage contributes to the reliability of the service. For organizations in the USA, particularly those providing transaction processing, analytics, payroll, financial, or other data-driven services, establishing and evidencing these controls can strengthen confidence in the reliability of their operations.

A well-defined SOC 2 processing integrity framework also requires organizations to look beyond individual controls and consider how processing risks, objectives, evidence, and monitoring work together. Choosing an experienced certification body is an important part of demonstrating that the control environment meets the applicable examination requirements. INTERCERT provides independent third-party SOC 2 examination services with an emphasis on professional, transparent, and objective assessment practices. As organizations strengthen the reliability of their processing environments and prepare to demonstrate that reliability to customers, a SOC 2 examination can turn processing integrity from an internal objective into measurable assurance that stakeholders can trust.