SOC 2 Processing Integrity for Compute and AI Infrastructure Providers

SOC 2 processing integrity is the optional Trust Services Category (criteria PI1.1 to PI1.5) that tests whether a system processes data completely, validly, accurately, on time and with authorization, measured against specifications the provider writes down. For neoclouds, GPU clouds, confidential-computing services and AI platforms, those specifications describe the job itself, so processing integrity speaks directly to what customers buy: a job that ran correctly on the inputs they sent.

A compute infrastructure company selling encrypted computation on its own accelerator hardware asked during SOC 2 scoping whether to add processing integrity to Security. Its cloud lead said it could be on the table because it is something we're sort of selling indirectly. Technical buyers of a new confidential-computing service will want to know how each computation stays complete, valid, accurate and timely.

What Is SOC 2 Processing Integrity?

SOC 2 processing integrity is the Trust Services Category that covers whether a system performs its intended functions free from error, delay, omission, and unauthorized or inadvertent manipulation. Every SOC 2 report includes Security; the other four categories are added based on commitments made to customers. The guide to the SOC 2 Trust Services Categories compares all five.

The provider defines what a correct job is, and the auditor tests whether controls keep processing consistent with that definition. A service that routes requests without transforming them defines a narrower scope (delivery and completeness) than one that compiles customer code and runs it on accelerators.

Why SOC 2 Processing Integrity Matters for Compute and AI Infrastructure Providers

SOC 2 processing integrity matters for compute providers because correct processing is the product they sell. A customer sending a training job, an inference request or an encrypted workload pays for the output, and the Security category says little about whether that output matches the input and the job specification. Three groups hear the question most:

• Neoclouds and GPU clouds that schedule customer training and inference jobs and return results or checkpoints.
• Confidential-computing and encrypted-compute providers, whose customers cannot inspect data in use and rely on the provider's assurance of correct computation.
• AI inference and training platforms that accept datasets, prompts or weights through an API and return outputs or fine-tuned models.

The guide to SOC 2 on a neocloud covers the infrastructure side: subservice organizations, CUECs and the bare metal responsibility split.

The Five SOC 2 Processing Integrity Criteria Applied to a Compute Service

The five processing integrity criteria follow a job from specification to storage. Criterion text is from the AICPA's 2017 Trust Services Criteria with 2022 revised points of focus.

The points of focus add detail. PI1.3 includes Detects and Corrects Processing or Production Activity Errors, and PI1.4 includes Distributes Output Only to Intended Parties, which on a multi-tenant GPU cloud means tenant isolation of results.

SOC 2 Processing Integrity Evidence for a GPU Cloud or AI Platform

SOC 2 processing integrity evidence for a compute platform comes mostly from systems the engineering team already operates: the API gateway, scheduler, CI pipeline and status page. The work is making those records complete, retained and traceable to a specification.

• Job specifications and API contracts: versioned schemas for inputs, processing behavior and outputs.
• Input validation logs, with the reason for each rejection.
• Job failure and retry records, including tickets for jobs corrected by hand.
• Checksum or hash verification of outputs that are files, checkpoints or model artifacts.
• Regression and correctness tests in CI for compilers, runtimes, kernels and drivers, comparing results to reference outputs.
• Release records showing those tests passed before production.
• Customer-facing status and incident records for processing errors.

How SOC 2 Processing Integrity Connects to Change Management (CC8.1)

SOC 2 processing integrity depends on change management, because a change to a compiler, runtime, kernel library or accelerator driver can alter computation results with no security event involved. CC8.1 requires changes to be authorized, designed, tested, approved and implemented; with processing integrity in scope, testing also covers correctness of results:

1. A correctness test suite that runs known inputs through the new build and compares outputs to reference results within defined tolerances.
2. A release gate that blocks promotion when correctness tests fail.
3. A release record linking the change ticket, test results, approver and deployment.

The SOC 2 CC8.1 change management guide covers the criterion in full, with variants for self-hosted GitLab and ticket-driven change management.

Why SOC 2 Processing Integrity Takes More Work Than Availability or Confidentiality

SOC 2 processing integrity takes more preparation than Availability or Confidentiality because it needs defined processing specifications and a process showing that inputs and outputs stay consistent with them, including across code changes. Availability builds on monitoring and recovery work a production platform already does, and Confidentiality on access control and encryption already in the Security category.

In Truvo's SOC 2 engagements, Availability and Confidentiality are part of the base SOC 2 build, and Processing Integrity and Privacy are typically scoped as an add-on. The guide to what SOC 2 costs covers how each added category affects readiness and audit effort.

When Should a Compute Provider Add SOC 2 Processing Integrity?

A compute provider should add SOC 2 processing integrity when correct results are the product and customers want independent assurance of them.

A Security-only first report is a common, sound choice, with processing integrity added once specifications and test records cover a full observation period. The SOC 2 for bare metal and on-prem infrastructure page covers the Security controls a hardware-owning provider builds first.

How SOC 2 Processing Integrity Relates to ISO 27001

SOC 2 processing integrity has partial overlap with ISO 27001:2022. Annex A controls 8.26 to 8.29 (application security requirements through security testing in development and acceptance) and 8.32 (change management) support the same engineering practices, with a focus on information security. Processing accuracy, completeness and timeliness need their own controls and evidence. The SOC 2 to ISO 27001 control mapping lists the PI1.1 to PI1.5 rows.

SOC 2 Processing Integrity Turns the Product Promise Into Audited Evidence

For a compute or AI infrastructure provider, SOC 2 processing integrity turns the job ran correctly into a tested claim backed by a written specification, input and output records, and correctness tests on every change to the processing stack. That evidence answers the question technical buyers ask during procurement, and keeps those deals moving.

More on-prem SOC 2 guides: the full on-prem security program checklist, SOC 2 Availability on a single data center and leaving an internal team out of SOC 2 scope.

Frequently Asked Questions

Is processing integrity required for SOC 2?

No. Security (the Common Criteria, CC1 to CC9) is the only required SOC 2 category. Processing integrity is one of four optional categories, added when a company commits to customers on complete, accurate and timely processing and they want independent assurance of it.

Who needs processing integrity in SOC 2?

Companies whose customers rely on the correctness of what the system produces: transaction processors, data processing services, and compute providers such as neoclouds, confidential-computing services and AI platforms. The clearest signal is a customer or RFP asking for it by name.

What is the difference between processing integrity and security in SOC 2?

The SOC 2 Security category covers protection of the system against unauthorized access, use and change. Processing integrity covers whether the system processes data as specified: complete, valid, accurate, timely and authorized. A well-secured platform can still return a wrong result after a runtime change; processing integrity controls catch that.

What are the SOC 2 processing integrity criteria?

There are five. PI1.1 covers processing specifications and definitions of data processed. PI1.2 covers inputs, PI1.3 covers processing, PI1.4 covers outputs, and PI1.5 covers storage of inputs, items in processing and outputs. They come from the AICPA's 2017 Trust Services Criteria with the 2022 revised points of focus.

Does an AI model's accuracy fall under SOC 2 processing integrity?

Processing integrity covers whether the system processes data according to the provider's specifications, such as running the requested model version on the submitted inputs and returning the complete output. Model quality claims, like benchmark scores, fall inside it only if the organization commits to them in its specifications and builds controls to support them.

Can we add processing integrity to SOC 2 in year two?

Yes. A Security-only first report followed by added categories later is common. Put the specifications, input and output records and correctness tests in place before the observation period that includes processing integrity, so the audit firm can test them across the full period.

How does change management affect SOC 2 processing integrity?

Change management (CC8.1) protects processing integrity, because changes to compilers, runtimes, kernels or drivers can alter results. The release process then includes correctness tests against reference outputs, a gate that blocks failing builds, and records linking each change to its tests and approval.

What evidence do auditors ask for in a SOC 2 processing integrity audit?

For a compute platform: job specifications and API contracts, input validation logs, job failure and retry records, output hashes or manifests, correctness test results in CI, release records, and incident records for processing errors, sampled across the observation period.

Does ISO 27001 cover SOC 2 processing integrity?

Partly. ISO 27001:2022 Annex A controls 8.26 to 8.29 and 8.32 cover secure development, testing and change management, which overlap with processing integrity practices. Processing accuracy, completeness and timeliness still need dedicated controls and evidence for a SOC 2 report.