Processing Execution and Exception Handling for SOC 2

What this control should accomplish

Critical workflows apply approved processing rules, compare expected and actual counts or results, detect incomplete, inaccurate, or repeated work, and carry exceptions through correction or reprocessing.

How to implement Processing Execution and Exception Handling

1. 1

   Map processing states

   Define the expected transformations, calculations, counts or values, stages, and terminal states for each critical flow, including failed, retried, cancelled, and manually corrected paths.

   You should end up with: Processing workflow and control design

2. 2

   Configure execution safeguards

   Implement sequencing, duplicate protection, retry limits, dependency checks, and control totals appropriate to the flow.

   You should end up with: Active workflow and retry configuration

3. 3

   Record each execution

   Retain a stable identifier, timing, rule version, expected and actual control totals or results, validation status, and a traceable output reference for each covered job, batch, or transaction.

   You should end up with: Searchable execution and result-validation record

4. 4

   Handle exceptions

   Route failed, partial, stuck, repeated, or manually corrected work to an owner and preserve the original event, action, and outcome.

   You should end up with: Traceable processing-exception record

5. 5

   Reconcile terminal states

   Compare accepted inputs with completed, rejected, failed, cancelled, and unresolved processing states and investigate differences.

   You should end up with: Periodic processing reconciliation

Evidence to keep, and what it should prove

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.

Which records should you prepare for the audit?

How an auditor may test this control

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.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Critical workflows apply approved processing rules, compare expected and actual counts or results, detect incomplete, inaccurate, or repeated work, and carry exceptions through correction or reprocessing.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Application Engineering / Service Operations), then compare dated records with the stated cadence: Continuous or per execution; exceptions reviewed at least weekly.

• Establish the complete audit record set

  Reconcile accepted input counts and relevant control totals to completed output counts and results, compare expected and actual values or inspected output for selected executions, and trace every difference, exception, and retry to a final disposition without removing duplicates or failures.

• Prepare the as-of-date evidence for a Type 1 engagement

  The current processing design and active workflow configuration plus one recent execution whose expected and actual counts, values, calculations, or inspected output were compared, and one exception or safely tested failure traced through final disposition at the review date.

• Prepare period evidence for a Type 2 engagement

  The complete system-generated population of covered processing executions with final status and expected-versus-actual control results, together with every failed, inaccurate, partial, retried, duplicated, or manually corrected occurrence and every scheduled reconciliation during the period.

• Inspect the policy / design artifacts

  Documents that define the control, its scope, ownership, and expected way of working.

  • Inspect Processing integrity policy or procedure

    For each selected record, confirm it demonstrates The shared process requires controlled execution, recorded status, exception ownership, reprocessing rules, and reconciliation for critical workflows.

    • Processing expectations
    • Responsible roles
    • Retry or correction expectations
    • Exception handling
    • Reconciliation cadence

  • Inspect Processing workflow and control design

    For each selected record, confirm it demonstrates The approved design defines transformations, calculations, expected counts or values, allowed states, sequencing, retries, duplicate safeguards, and failure handling.

    • Workflow name
    • Transformation or calculation rules
    • Expected count, value, or result
    • State or stage definitions
    • Retry limit
    • Duplicate safeguard
    • Failure route

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect Policy approval and version record

    For each selected record, confirm it demonstrates The execution and exception-handling requirements have been approved and are effective for the period under review.

    • Document name
    • Version
    • Approver
    • Effective date
    • Approval record

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect Active workflow and retry configuration export

    For each selected record, confirm it demonstrates The live environment implements the approved workflow stages, processing version, retry limits, duplicate safeguards, control checks, and failure route.

    • Workflow and environment
    • Active rule or release version
    • Configured stages and transitions
    • Retry and duplicate settings
    • Control-check configuration
    • Failure or escalation route
    • Export or capture time

  • Inspect Processing execution and control-total results

    For each selected record, confirm it demonstrates Covered executions retain status plus expected-versus-actual counts, values, calculations, or inspected output results that show the processing result was complete and correct.

    • Execution ID and flow
    • Start and completion time
    • Processing rule version
    • Expected count, value, or result
    • Actual count, value, or result
    • Validation status
    • Output sample or result reference

  • Inspect Processing exception and reconciliation record

    For each selected record, confirm it demonstrates Failed, partial, stuck, duplicated, retried, or corrected processing is accounted for from detection through disposition.

    • Exception ID
    • Related execution ID
    • Detected condition
    • Owner
    • Correction or reprocessing action
    • Final status
    • Reconciliation period

• Trace the control from design to operation

  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.

Common implementation and evidence gaps

• Only successful jobs are retained in the population.
• A job is treated as accurate because it completed successfully even though no expected result, control total, calculation, or output sample was checked.
• The approved processing design and active workflow configuration use different rules or retry behavior.
• Retries can create duplicate results because the workflow lacks duplicate protection.
• Failed or stuck items remain in queues without an accountable owner.
• Manual corrections do not preserve the original value, actor, or reason.
• An alert closes when the job restarts even though the final result is not verified.

Before you call this control ready

• Can one input be traced through every significant processing state?
• Does each covered execution retain an expected-versus-actual count, value, calculation, or inspected output result?
• Are failed, partial, duplicate, out-of-order, and retried executions visible?
• Does reprocessing avoid creating an additional unintended result?
• Can one exception be traced from detection through correction and closure?
• Do accepted inputs reconcile to all terminal processing states?

Trust Services Criteria references

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.

• PI1.3

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.

Related controls to review next