Repeated findings are useful only when they stay accurate. The SOC 2 Processing Integrity Default Findings Engine lets an authorized team leader or admin save a reusable starting point against a canonical processing-integrity criterion. It reduces repeated typing while leaving the actual observation, evidence, scope, and validation inside each project finding.
What this solves
Fintech, payment, and data-service teams repeatedly identify stale reconciliations, incomplete exception review, unauthorized adjustments, missing input validation, and untimely processing. If each reviewer uses different language, management may fail to see that several symptoms arise from the same processing objective.
Before you begin
- Sign in as a team leader or team admin with access to the local engine.
- Confirm that SOC 2 Processing Integrity is the correct Library for the work.
- Choose a recurring issue pattern, not one client-specific finding.
- Remove names, URLs, selectors, credentials, personal data, dates, and evidence from the reusable wording.
- Keep the official AICPA Trust Services Criteria - Processing Integrity scope and terminology available for reference.
Step-by-step
- Define the processing objectives and service commitments before authoring defaults.
- Choose the exact Processing Integrity criterion in the local engine.
- Describe the recurring failure in terms of completeness, validity, accuracy, timeliness, or authorization.
- Add evidence expectations for populations, samples, reconciliations, or exception handling.
- Write remediation around the control outcome and review responsibility.
- Add transaction samples, dates, systems, and exception results only to the project record.
What the default saves
A local default can save the summary, description, remediation guidance, severity behavior, and canonical processing-integrity criterion mapping. When a reviewer selects it from New Finding, voiqq prefills those values. The new finding still starts Open with Pending validation and must be changed to match the real observation.
Good patterns to predefine
- Reconciliation exceptions remain unresolved beyond the defined processing target.
- Input validation does not prevent incomplete or invalid transactions from entering processing.
- Manual adjustments lack authorization or an independent review record.
- Failed or duplicate processing is not detected and corrected promptly.
- Output completeness and accuracy checks are not evidenced for the in-scope period.
Check your result
- Do not put transaction data or customer identifiers in a default.
- Separate one processing exception from a control-pattern finding.
- Keep the evidence period and sample in the project.
- Check that remediation addresses the processing objective.
- Validate with a new sample when appropriate.