Skip to content

SOC 2® processing integrity in plain English (PI1.1 to PI1.5)

Unofficial plain-English guide. Not affiliated with or endorsed by the AICPA. Read the AICPA’s own criteria

An unofficial plain-English look at the SOC 2 processing integrity criteria, PI1.1 to PI1.5: what the system should do, and checks on data in, processing, out, and stored.

By Blank Slate Creative.

OrderFive custom security policies, $85 flat. Markdown, Word, and PDF.

Order the five policies

Does the system do what you say it does with the data you give it?

Processing integrity is the category that is hardest to picture until you think of a system whose output a customer relies on being right: payments, payroll, billing, analytics, anything that calculates.

The five criteria follow the data’s path: what the system should do, what comes in, how it is processed, what goes out, and what is stored. If you already validate inputs, monitor jobs, and reconcile outputs, you do much of this today. The work is writing it down and keeping the checks.

Where a small team starts

Pick your most important data flow and draw it on one page: where data enters, what transforms it, and where it ends up. Under each step, write the check that would catch a bad record and where the alert goes.

That page is the seed of everything else here. Expect to find at least one step with no check at all.

The criteria, PI1.1 to PI1.5

Below are our short labels, what the criteria are about, and examples of what a small team might do or keep. The examples are our own views, not requirements of the standard.

PI1.1: Defining what processing should do

The company writes down what its processing should accomplish and what each kind of data means, so quality can be judged against that. Specs, definitions, and customer-facing descriptions all count.

In practice

  • A data dictionary for the fields that matter most.
  • Customer documentation that describes outputs and their limits.
  • A written rule for how a key number, such as an invoice total, is calculated.
  • A log of changes to those definitions.

PI1.2: Checking data on the way in

Data coming in is tested for gaps and errors before it is processed. Validation rules and reconciliations are the usual tools.

In practice

  • Schema validation on API requests and file uploads.
  • A queue for rejected records that someone reviews.
  • Control totals compared between the source and what was ingested.
  • An alert when an expected file doesn’t arrive.

PI1.3: Processing that runs as designed

Processing steps follow their specification, and failures are noticed and fixed. Reviewers look at monitoring and at what happens to failed items.

In practice

  • Job monitoring that alerts on failures.
  • A dead-letter queue that someone works through every day.
  • Automated tests for calculation logic in the build pipeline.

PI1.4: Right results to the right people

What the system sends out, such as reports, exports, and notifications, should be right, arrive when expected, and reach only the people meant to see it.

In practice

  • Reports delivered through access-controlled channels, not open links.
  • A check that record counts in an export match the source.
  • Delivery logs and bounce reviews for scheduled sends.
  • Monitoring of how late scheduled outputs run.

PI1.5: Keeping stored records intact

A record that sits in storage should still say what it said the day it was saved. Reviewers look for ways to notice when it doesn’t, such as audit trails and integrity checks.

In practice

  • Database constraints and checksums on stored files.
  • Versioned or append-only storage for records that must not be rewritten.
  • An audit trail of who edited a record, and when.

Questions worth being able to answer

These are ours, not a list of what an examiner will ask. If you can answer each in a sentence, and show where the proof lives, you are in good shape for the conversation.

  • How do you know a bad record didn’t get through?
  • What happens to a job that fails?
  • How do you reconcile what you received with what you processed?
  • Who can change a calculation, and how is the change tested?

More topics in this guide

This page is one part of our unofficial guide to the SOC 2 Trust Services Criteria. Here are the others.

Related guides

About this guide and the study tool

Who we are, and aren’t

Blank Slate Creative, LLC is not affiliated with, endorsed by, or sponsored by the AICPA, CIMA, or the Association of International Certified Professional Accountants. We are not a CPA firm. Only a licensed CPA firm can perform a SOC 2 examination and issue a report.

What this is, and isn’t

This is an unofficial, plain-English explanation written by Blank Slate Creative, LLC. It is not the Trust Services Criteria, and it does not reproduce or replace them.

It is not legal, audit, or attestation advice.

Using this guide or the study tool does not mean you will pass an audit or satisfy any customer or auditor.

The “in practice” notes and examples are our own views, not requirements of the standard.

Written about the 2017 criteria with the 2022 revised points of focus. The AICPA may revise them.

Read the AICPA’s own publication for the authoritative wording. The PDF download asks for a free AICPA account.

Trademarks

AICPA and American Institute of CPAs are trademarks of the American Institute of Certified Public Accountants and are registered in the US, the EU and other countries.

SOC 1®, SOC 2® and SOC 3® trademarks are registered trademarks of the AICPA.

← All guides