Processing Integrity
The organization defines what correct processing looks like for each critical in-scope flow, including its data sources, rules, expected results, timing targets, dependencies, owners, and customer responsibilities, and communicates current specifications and material changes to affected teams and customers.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
The team can identify one or more critical processing flows, explain in measurable terms what each flow should receive, do, and produce, and show that affected users received the current specifications and responsibilities.
First SOC 2 program
Start with one or two customer-critical flows. Document the source, major steps, expected result, timing target, owner, and customer responsibilities, then publish the relevant parts to the people who operate or depend on the flow.
As the company scales
Maintain versioned specifications linked to product requirements, system designs, monitoring, tests, customer responsibilities, material-change reviews, and retained publication or notification records.
Select the workflows where missing, incorrect, delayed, or unauthorized processing would materially affect customers or commitments.
You should end up with: Short list of in-scope processing flows
For each flow, record its input, source, processing purpose, expected output, allowed timing, owner, and measurable success conditions.
You should end up with: Processing objective for each flow
Show the major systems, queues, stores, integrations, and handoffs from intake through delivery and retention.
You should end up with: Current processing-flow diagram
Link each important expectation to a validation rule, reconciliation, alert, test, or review that shows whether the flow is working.
You should end up with: Objective-to-check trace
Require product, data-flow, integration, and customer-responsibility changes to identify whether the objective or supporting checks must be updated.
You should end up with: Material-change review record
Publish the applicable operating instructions, customer responsibilities, and material changes to affected teams or customers and retain who was notified, when, and which version they received.
You should end up with: Publication or notification record tied to the effective version
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
Management has established a common process for defining, approving, operating, reviewing, and correcting critical processing flows.
Include this context
Purpose
Include this context
Scope
Include this context
Responsible roles
Include this context
Review cadence
Include this context
Exception handling
Weak evidence to avoid
A generic security policy that does not identify processing responsibilities, required reviews, or exception handling.
Confirm what the record proves
Critical flows have defined sources, rules, expected results, timing targets, dependencies, owners, and customer assumptions.
Include this context
Flow name
Include this context
Input and source
Include this context
Major processing steps
Include this context
Expected output
Include this context
Timing target
Include this context
Owner
Include this context
Customer responsibility
Weak evidence to avoid
A high-level architecture image without expected results, timing, ownership, or customer responsibilities.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
The applicable processing procedure has an identifiable version, authorized approval, effective date, and scheduled review.
Include this context
Document name
Include this context
Version
Include this context
Approver
Include this context
Approval date
Include this context
Effective date
Include this context
Next review date
Weak evidence to avoid
An undated document with no approver, version history, or evidence that it is currently effective.
Confirm what the record proves
Changes affecting processing behavior were evaluated for updates to objectives, data flows, controls, monitoring, and customer responsibilities.
Include this context
Change ID
Include this context
Affected flow
Include this context
Change date
Include this context
Integrity impact
Include this context
Reviewer
Include this context
Decision and follow-up
Weak evidence to avoid
A release ticket that describes the feature but does not assess its effect on processing expectations or checks.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Each material processing expectation is tied to an implemented check and has been validated against the intended system or workflow.
Include this context
Flow and objective
Include this context
Validation rule or check
Include this context
System and environment
Include this context
Validation date
Include this context
Reviewer
Include this context
Result
Weak evidence to avoid
A green screenshot with no identified flow, scope, date, reviewer, or explanation of what was validated.
Confirm what the record proves
Affected operators and customers received the applicable processing instructions, responsibilities, or material-change notice tied to the version placed into effect.
Include this context
Specification or notice version
Include this context
Affected audience
Include this context
Publication or send time
Include this context
Communication channel
Include this context
Publisher or sender
Include this context
Delivery or publication result
Weak evidence to avoid
A current help page or announcement with no effective version, affected audience, publication date, sender, or retained delivery record.
Type 1
The current approved procedure, specifications for the selected critical flows, one recent objective-to-check trace, and retained publication or notification evidence showing affected users received the effective specification at the review date.
Type 2
Every scheduled processing-objective review and every material product, integration, customer-responsibility, or data-flow change during the period, including the resulting specification decision and each required publication or notification to affected users.
Reconcile the critical-flow list to a current specification, reconcile material changes and scheduled reviews to completed impact decisions, and trace each changed responsibility or user-facing specification to a retained publication, notification, or documented no-notification decision.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: The team can identify one or more critical processing flows, explain in measurable terms what each flow should receive, do, and produce, and show that affected users received the current specifications and responsibilities.
Compare the documented owner with the intended role (Product Owner / Engineering Owner), then compare dated records with the stated cadence: At least annually and upon material change.
Reconcile the critical-flow list to a current specification, reconcile material changes and scheduled reviews to completed impact decisions, and trace each changed responsibility or user-facing specification to a retained publication, notification, or documented no-notification decision.
The current approved procedure, specifications for the selected critical flows, one recent objective-to-check trace, and retained publication or notification evidence showing affected users received the effective specification at the review date.
Every scheduled processing-objective review and every material product, integration, customer-responsibility, or data-flow change during the period, including the resulting specification decision and each required publication or notification to affected users.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Management has established a common process for defining, approving, operating, reviewing, and correcting critical processing flows.
For each selected record, confirm it demonstrates Critical flows have defined sources, rules, expected results, timing targets, dependencies, owners, and customer assumptions.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates The applicable processing procedure has an identifiable version, authorized approval, effective date, and scheduled review.
For each selected record, confirm it demonstrates Changes affecting processing behavior were evaluated for updates to objectives, data flows, controls, monitoring, and customer responsibilities.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Each material processing expectation is tied to an implemented check and has been validated against the intended system or workflow.
For each selected record, confirm it demonstrates Affected operators and customers received the applicable processing instructions, responsibilities, or material-change notice tied to the version placed into effect.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.