Processing Integrity
Outputs from critical processing flows are checked against expected content, control totals, timing, and destination rules, released only to intended recipients, and monitored for inaccurate, missing, late, duplicate, failed, or unauthorized delivery.
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
Critical outputs match expected content and control totals, follow destination rules, reach intended recipients on time, and produce visible exceptions when results are inaccurate, missing, repeated, late, or unauthorized.
First SOC 2 program
Define the expected fields or result, recipient, and timing for each critical output. Compare one produced output with that definition, keep its delivery status, and send differences or failures to an owner.
As the company scales
Use versioned output schemas, content or control-total validation, recipient authorization, delivery acknowledgments, duplicate protection, timing targets, population reconciliation, and automated exception routing.
Record the required content, format, destination, authorized recipient, timing target, and delivery success condition for each critical flow.
You should end up with: Output and delivery specification
Apply recipient authorization, format validation, duplicate protection, and release conditions before the output leaves the workflow.
You should end up with: Active output and delivery configuration
Compare required fields, record counts, control totals, calculations, or an inspected output sample with the approved specification before or immediately after release.
You should end up with: Expected-versus-actual output validation result
Retain a stable output ID, destination, release time, delivery status, acknowledgment where available, and any retry.
You should end up with: Searchable output-delivery record
Assign missing, late, failed, duplicated, misdirected, or manually delivered outputs to an owner and record the resolution.
You should end up with: Output-exception record
Compare created outputs with delivered, failed, pending, cancelled, and corrected outcomes and investigate differences.
You should end up with: Periodic output reconciliation
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
The shared process sets expectations for output validation, authorized delivery, exception resolution, and reconciliation.
Include this context
Output-control expectations
Include this context
Delivery responsibilities
Include this context
Authorization requirement
Include this context
Exception handling
Include this context
Reconciliation cadence
Weak evidence to avoid
A policy that requires accurate reports but does not address recipients, delivery status, failures, or reconciliation.
Confirm what the record proves
Critical outputs have an approved design for required content, control totals or calculations, destination, recipient authorization, timing, duplicate handling, and failure behavior.
Include this context
Output type
Include this context
Required content or format
Include this context
Expected control total or calculation
Include this context
Destination
Include this context
Authorized recipient rule
Include this context
Timing target
Include this context
Failure behavior
Weak evidence to avoid
A report definition that does not identify the destination, authorized recipient, delivery timing, or failed-delivery action.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
The output-control requirements are covered by an authorized procedure that was effective during the relevant period.
Include this context
Document name
Include this context
Version
Include this context
Approver
Include this context
Approval date
Include this context
Effective period
Weak evidence to avoid
A policy file with no approval history or evidence that its version applied during the review period.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The live environment implements the designed output schema, validation rule, recipient restriction, duplicate safeguard, timing threshold, and failure route.
Include this context
Output flow and environment
Include this context
Active specification or rule version
Include this context
Content-validation setting
Include this context
Recipient restriction
Include this context
Duplicate and timing settings
Include this context
Failure route
Include this context
Export or capture time
Weak evidence to avoid
A settings screenshot without the output flow, environment, active rules, destination restrictions, failure route, or capture time.
Confirm what the record proves
Produced outputs retain expected-versus-actual content or control results together with destination, release time, delivery status, acknowledgment, and retry history.
Include this context
Output ID and specification version
Include this context
Expected content, count, or value
Include this context
Actual content, count, or value
Include this context
Validation result or inspected sample reference
Include this context
Recipient or destination
Include this context
Release time
Include this context
Delivery status and acknowledgment
Weak evidence to avoid
A sent or delivered status with no expected-versus-actual content check, control total, inspected sample, specification version, or destination context.
Confirm what the record proves
Missing, late, duplicated, failed, corrected, or unauthorized delivery events were included in the population and resolved or escalated.
Include this context
Covered period
Include this context
Produced count
Include this context
Delivered count
Include this context
Exception ID
Include this context
Exception owner
Include this context
Resolution
Include this context
Remaining difference
Weak evidence to avoid
A delivery success percentage that omits pending and failed outputs and cannot be tied to individual exceptions.
Type 1
The current output design and active delivery configuration plus one recent output traced through expected-versus-actual content or control-total validation, authorized destination, and delivery result, along with one failed or safely tested exception at the review date.
Type 2
The complete system-generated population of covered outputs with content-validation and delivery outcomes, including accurate, inaccurate, successful, failed, pending, retried, duplicated, cancelled, corrected, and manually delivered records, plus every scheduled output reconciliation during the period.
Reconcile produced output IDs and control totals to validated, delivered, failed, pending, cancelled, and corrected outcomes; compare selected output content with the effective specification, then match every content or delivery exception to its owner and final disposition.
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: Critical outputs match expected content and control totals, follow destination rules, reach intended recipients on time, and produce visible exceptions when results are inaccurate, missing, repeated, late, or unauthorized.
Compare the documented owner with the intended role (Product Operations / Application Engineering), then compare dated records with the stated cadence: Continuous or per delivery; exceptions reviewed at least weekly.
Reconcile produced output IDs and control totals to validated, delivered, failed, pending, cancelled, and corrected outcomes; compare selected output content with the effective specification, then match every content or delivery exception to its owner and final disposition.
The current output design and active delivery configuration plus one recent output traced through expected-versus-actual content or control-total validation, authorized destination, and delivery result, along with one failed or safely tested exception at the review date.
The complete system-generated population of covered outputs with content-validation and delivery outcomes, including accurate, inaccurate, successful, failed, pending, retried, duplicated, cancelled, corrected, and manually delivered records, plus every scheduled output reconciliation during the period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The shared process sets expectations for output validation, authorized delivery, exception resolution, and reconciliation.
For each selected record, confirm it demonstrates Critical outputs have an approved design for required content, control totals or calculations, destination, recipient authorization, timing, duplicate handling, and failure behavior.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates The output-control requirements are covered by an authorized procedure that was effective during the relevant period.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates The live environment implements the designed output schema, validation rule, recipient restriction, duplicate safeguard, timing threshold, and failure route.
For each selected record, confirm it demonstrates Produced outputs retain expected-versus-actual content or control results together with destination, release time, delivery status, acknowledgment, and retry history.
For each selected record, confirm it demonstrates Missing, late, duplicated, failed, corrected, or unauthorized delivery events were included in the population and resolved or escalated.
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.