System Processing Policies
| Field | Value |
|---|---|
| Version | 1.0 |
| Effective Date | April 2026 |
| Review Cycle | Annual |
| Document Owner | Chief Information Security Officer (CISO) |
| Classification | CONFIDENTIAL — Internal Use Only |
| Applicable Standard | SOC 2 Type II — Security, Availability, Confidentiality |
1. Purpose and Scope
This document defines the policies and procedures governing system processing within QA Touch, specifying how data is processed accurately, timely, and consistently to produce reliable outputs including test results, generated reports, integration events, AI-generated content, and exported data. Supports SOC 2 Processing Integrity criteria PI1.4 (Processing is Complete and Accurate) and PI1.5 (Output is Complete and Accurate).
2. Core Processing Principles
| Principle | Implementation in QA Touch |
|---|---|
| Completeness | All authorised inputs that pass validation are processed. No records are silently dropped; failures generate logged errors and user notifications. |
| Accuracy | Processing logic transforms inputs without data corruption. Transformation steps (sanitisation, default-value application, type coercion) are deterministic and testable. |
| Timeliness | Processing occurs within defined SLA windows (see Section 5). Degradation or failure is detected within defined thresholds and escalated to the on-call engineer. |
| Atomicity | All database write operations are wrapped in ACID transactions. Partial writes are rolled back on any failure; the system is never left in an inconsistent state. |
| Idempotency | Repeated processing of the same input (e.g., webhook retries) produces the same result without creating duplicate records. Idempotency keys used for critical operations. |
| Auditability | All processing events are logged with sufficient actor, action, resource, and outcome detail to reconstruct the complete sequence of operations. |
| Scope Isolation | All processing is scoped to the authenticated workspace. Cross-workspace data access is architecturally prevented at the query and processing layers. |
3. Core Processing Workflows
3.1 Test Case Create / Update
- API receives authenticated, authorised request. Schema and business rule validation applied.
- Input sanitised (XSS strip); audit metadata attached (actor ID, UTC timestamp, workspace ID).
- Record written to primary database within an ACID transaction; unique ID generated.
- Audit log event appended (append-only, tamper-evident): actor, action=CREATE/UPDATE, resource=test_case, resource_id, field diff.
- Search index update queued asynchronously; index failure does not block or roll back the primary write.
- Configured subscribers notified via async notification queue; delivery failures retried with exponential backoff.
- API returns HTTP 201/200 with the fully persisted record confirming all committed field values.
3.2 Test Run Execution
- Each step result submission (Pass/Fail/Blocked/etc.) is written transactionally; run completion percentage recomputed atomically.
- Linked defect IDs validated against workspace records before commit; invalid references return HTTP 422.
- On run completion (all steps submitted or explicit closure by tester), a run-completion event is written; notifications triggered.
- Report aggregates updated asynchronously; dashboard metrics reflect completed run within defined SLA.
3.3 Integration Sync Processing
- Inbound webhook events authenticated via HMAC-SHA256 before queuing. Unknown event types rejected.
- Queue processing is idempotent: events with duplicate event IDs are deduplicated and silently skipped.
- Field mapping applied per workspace integration configuration; unmapped fields logged and ignored without error.
- Sync failures trigger retry (up to 3 attempts with exponential backoff); persistent failures alert workspace admin and move to dead-letter queue.
3.4 AI Test Generation
- Prompt/file input validated (length, type, size). QA Touch composes a structured prompt using workspace context; no cross-workspace data included.
- API request transmitted to third-party LLM provider over TLS 1.3. Response validated for schema conformance.
- Generated test cases displayed in review UI; no content is auto-saved without explicit user action.
- AI request metadata logged: user ID, workspace ID, model identifier, token count, timestamp (prompt content per retention policy [VERIFY]).
3.5 Import Processing
- File stored in isolated temporary staging path immediately after upload; not accessible to other users or workspaces.
- Row-by-row parsing and validation; user presented with preview (valid count, error count) before confirmation.
- On user confirmation: all valid rows committed in a single database transaction; staging file deleted immediately.
- On cancellation or failure: staging file and any intermediate records purged; primary data store unaffected.
3.6 Report and Export Generation
- Queries scoped strictly to requesting user’s workspace and RBAC-permitted project set; cross-workspace data access impossible.
- Large reports generated asynchronously; user notified via in-app notification and email when ready.
- Generated files stored in object storage with a time-limited pre-signed URL; file deleted automatically after TTL expires.
4. Error and Exception Handling
- All unhandled exceptions caught by global error handler; HTTP 500 returned with generic message; full stack trace logged internally.
- Error responses never expose internal architecture, database schema names, or stack traces to the client.
- Persistent processing failures (queue backlog, DB connectivity loss) trigger operational alerts within 5 minutes.
- Failed async jobs (notifications, index updates, export generation) retried automatically; after max retries, moved to dead-letter queue for manual review.
5. Processing SLAs
| Processing Activity | Target Completion | Alert Threshold |
|---|---|---|
| API CRUD operations | < 500ms p99 | Sustained > 1,000ms p99 |
| Test run step result submission | < 1 second | Sustained > 3 seconds |
| Integration sync event processing | < 30 seconds from receipt | Sustained > 2 minutes |
| AI test case generation | < 15 seconds | Sustained > 60 seconds |
| Standard report / export generation | < 10 seconds | Sustained > 60 seconds |
| Large report generation (async) | < 5 minutes; user notified | Sustained > 15 minutes |
| Import processing (up to 1,000 rows) | < 60 seconds | Sustained > 300 seconds |
| Email notification delivery | < 2 minutes | Sustained > 10 minutes |
ASSUMPTION: SLA values above are illustrative targets. Verify actual committed values with QA Touch engineering and SRE teams before presenting to auditors.