Service organizations often need to achieve SOC 2 compliance to assure partners and clients of their sound security and operational practices. One of the trust criteria assessed is processing integrity, which involves a set of controls for objectives, inputs, processes, outputs, and storage.

Is your organization ready for SOC 2 compliance? Schedule a consultation to find out!

Understanding Processing Integrity for SOC 2 Audits

The SOC compliance frameworks are overseen by the American Institute of Certified Public Accountants (AICPA). Current or prospective partners often ask organizations to produce a SOC 2 report to provide security assurance, and compliance requires installing and testing a set of baseline controls. Audits often include additional controls for specific criteria.

To appreciate the role of processing integrity controls in SOC 2 compliance, you’ll need:

• Some baseline context for SOC compliance and the whole set of requirements
• An overview of the processing integrity controls and what exactly they entail
• Additional considerations for implementation and planning for an assessment

The most effective way to implement all required controls and prepare for an audit is to work with a dedicated compliance partner who can advise and oversee all parts of the process.

The Trust Services Criteria for SOC 2 Compliance

The AICPA oversees multiple SOC compliance standards, but the most widely applicable SOC report is SOC 2. A SOC 2 report measures service organizations’ adherence to the AICPA’s Trust Services Criteria (TSC) framework. The TSC, also known as trust service principles (TSP), are security, availability, processing integrity, confidentiality, and privacy. All SOC 2 audits cover these principles across a set of Common Criteria (CC) that are required for all eligible entities.

The CC series includes two major groupings of controls—

Baseline Common Criteria

These controls are the most fundamental parts of sound technical and security operations. The CC series requirements are divided as follows:

• CC1: The Control Environment
• CC2: Communication and Information
• CC3: Risk Assessment
• CC4: Monitoring Activities
• CC5: Control Activities

Supplemental Common Criteria

These controls build upon the baseline set by CC 1–5, adding more granular, robust, and flexible assurance across the organization:

• CC6: Logical and Physical Access Controls
• CC7: System Operations
• CC8: Change Management
• CC9: Risk Mitigation

The full SOC 2 controls list includes further enumerated requirements (e.g., CC1.1, CC1.1, etc.) based on the COSO Principles. See our reporting checklist or whitepaper for more information.

All individual criteria are touched on across these controls, with a special focus on security, which is heavily emphasized in all of them. In addition, some organizations may be audited on Additional Criteria that correspond exclusively to the other four TSC, like processing integrity.

Processing Integrity Controls for SOC 2 Compliance

Organizations that need a SOC 2 report with a processing integrity focus need to implement all CC controls and their points of focus, along with the Additional Criteria detailed in the TSC. In practice, the other trust service criteria have special points of focus spelled out across the CC series, but there are no such specifications for processing integrity. However, organizations requiring a report on PI may also require reports on the other Additional Criteria. Careful communication with clients and other stakeholders will determine your scope accurately.

Processing integrity does have a set of Additional Criteria, including five requirements and several specific points of focus, that all entities requiring this report need to have in place. Below, we’ll break down the specific controls enumerated in the PI Additional Criteria.

PI1.1: Communication of Objectives

This control is about setting clear expectations for what processing integrity should look like within your organization’s technological systems. The text of the base control reads as follows:

“The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.”

There are two points of focus highlighting critical characteristics for all PI-specific assessments:

• Identifying both functional and non-functional requirements for specifications
• Defining the data necessary for adequate support of a product or service —
  • Making definitions and purposes of data available to all users
  • Including data population, nature, sources, scale, and other factors
  • Ensuring accuracy and completeness across all data definitions
  • Identifying information necessary to understand data elements

In addition, there is one point of focus applicable to systems producing or distributing products:

• Defining the data necessary for adequate support of a good or product
• Making relevant data available to end users
• Ensuring data identifiability and accessibility
• Validating data for completeness and accuracy

Work with an advisor to determine whether/how this last criterion applies (and how to meet it).

PI1.2: Control Over System Inputs

This control starts a set of three requirements covering governance of system inputs, processing, and outputs, respectively. All center around sound policies and procedures. The text of this control reads as follows:

“The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity’s objectives.”

There are three points of focus applicable to all PI-intensive SOC 2 assessments:

• Defining characteristics for processing inputs necessary to meet objectives
• Evaluating processing inputs relative to compliance requirements and goals
• Creating and maintaining clear and accurate records of all system inputs

The “objectives” referred to here and below refer back to the expectations set per PI1.1, along with any other formal objective-setting the organization has done for overall SOC 2 compliance.

PI1.3: Control Over System Processing

This control builds on the prior one, extending protections and sound governance to the actual processing that occurs on, with, and concerning system inputs. Its language reads as follows:

“The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity’s objectives.”

There are five defined points of focus for meeting this criterion:

• Defining processing specifications necessary for meeting compliance requirements
• Defining processing activities that system inputs can be expected to be subjected to
• Detecting and correcting errors and inconsistencies across processing activities
• Recording processing activities as they occur and maintaining accurate records
• Processing inputs in a complete, accurate, and timely manner as defined per PI1.1

These processes work best when fully integrated into a sound cyberdefense monitoring apparatus that ensures visibility and control across all organizational technological systems.

PI1.4: Control Over System Outputs

As with PI1.3, this control builds on the requirements for inputs and processing, ensuring that the outputs of said processes are as expected—and protected. Its language reads as follows:

“The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity’s objectives.”

There are four points of focus applicable to this control across all assessments:

• Protecting outputs from theft, destruction, and other forms of compromise
• Ensuring outputs are distributed only to authorized and intended recipients
• Distributing outputs completely and accurately and maintaining data integrity
• Creating and maintaining clear, accurate records of outputs and related activities

PI1.4 concludes the before-during-after sequence of specifications for securing processing integrity across all system processes. However, it’s not the final set of concerns to manage.

PI1.5: Secure Storage at All Stages

The last SOC 2 control detailed for processing integrity involves securing all data related to all elements of information processing in storage. The language of this control reads as follows:

“The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity’s objectives.”

There are four final points of focus for the PI-specific portion of a SOC 2 audit:

• Protecting stored information on inputs, processes, and outputs from compromise
• Archiving and protecting relevant system records from compromise and deterioration
• Ensuring data stored is complete and accurate while maintaining data integrity long-term
• Creating and managing clear, accurate, and timely records of system storage activities

Working with an advisor is the best way to deliver on these and all other requirements.

Additional SOC 2 Compliance Considerations

As noted above, there are many variations of SOC compliance that organizations may have to achieve, depending on business function, industry, and client expectations. SOC 2 is the most common, as it applies across all service organizations and may be an explicit requirement or a de facto mandate for doing business with certain partners. It’s not required by law in any US or global jurisdiction, at least at present, but it is something of a gold standard in many contexts.

Aside from SOC 2, there are also SOC 1 and SOC 3 audits that you may need to prepare for.

• SOC 1 applies specifically to financial services providers and/or the financial services wings of entities that provide a multitude of services. It assesses an organization’s Internal Control over Financial Reporting (ICFR), utilizing a different, parallel framework to the TCS detailed above.
• SOC 3 reports are similar to SOC 2 but are intended for a different audience. SOC 2 is for specialized, technical audiences such as auditors and analysts who require information in specific formal structures. They are not intended for public use in any way. SOC 3 reports, in contrast, are intended for a general audience and are usually generated for publication on an entity’s website or other public-facing forum. Many entities get both a SOC 2 and a SOC 3 report.

Aside from framework differences, there are also multiple “types” of assessments.

Both SOC 1 and SOC 2 come in Type 1 and Type 2 variants. A Type 1 report focu