Process Flow Diagrams
| 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 provides narrative descriptions of the principal data and processing flows within QA Touch, serving as written process flow documentation for SOC 2 auditors. These narratives supplement visual flow diagrams maintained by the QA Touch engineering team and support PI1 (Processing Integrity) and CC6 (Logical Access Controls) criteria.
ASSUMPTION: Visual process flow diagrams (swimlane, BPMN, or flowchart format) are maintained separately by QA Touch engineering in an internal architecture repository. This document provides the SOC 2 narrative equivalent. Both should be provided to auditors together.
2. Flow 1 — User Authentication and Session Establishment
| # | Activity | Actor / System | Controls Applied |
|---|---|---|---|
| 1 | User navigates to QA Touch login URL over HTTPS. | User / Browser | TLS 1.2+ enforced; HSTS header present; no HTTP redirect loop |
| 2 | User submits email and password, OR initiates SSO flow via identity provider button. | User | CSRF token validated on form submit; rate limiting on login endpoint |
| 3 | Application validates credentials: password compared against Argon2id hash in database, OR SSO token signature verified against IdP public key. | Application / IdP | Plaintext password never stored; constant-time comparison used; SSO tokens verified cryptographically |
| 4 | If MFA is enabled on the account, a TOTP or push-notification challenge is issued. Maximum 3 failed MFA attempts before temporary lockout. | Application / MFA Provider | TOTP: RFC 6238; lockout prevents brute-force; lockout duration configurable [VERIFY] |
| 5 | On successful authentication, a cryptographically random session token is generated and stored server-side. A short-lived, signed cookie is issued to the browser. | Application | Cookie: HttpOnly; Secure; SameSite=Strict; not accessible to JavaScript |
| 6 | User is directed to their workspace dashboard. RBAC permissions loaded for the session from the database. | Application | Permissions scoped to workspace; role checked on every subsequent request |
| 7 | Session TTL extended on each active request up to the absolute maximum (24h [VERIFY]). Idle timeout enforced server-side (30 min [VERIFY]). | Application | Timeout enforced server-side; client-side idle detection as defence-in-depth only |
| 8 | On explicit logout or session expiry: session token invalidated server-side; cookie cleared; user redirected to login. | User / Application | Token invalidation is immediate and permanent; cannot be replayed after invalidation |
3. Flow 2 — Test Case Creation (Web UI)
| # | Activity | Actor / System | Controls Applied |
|---|---|---|---|
| 1 | Authenticated user navigates to a project and selects ‘New Test Case’. | User | Session token validated; RBAC: user must have ‘create test case’ permission for the project |
| 2 | User completes form: title, test steps, priority, status, tags, custom fields. | User | Client-side validation: required fields highlighted; character counters shown |
| 3 | User submits form; browser sends POST /api/v1/test-cases with session token and CSRF token. | Browser / Application API | CSRF token validated; Content-Type checked; request body size checked |
| 4 | API validates request payload: schema, required fields, enum values, referential integrity. | Application | HTTP 422 returned on failure with structured field-level error detail; nothing written to DB |
| 5 | Input sanitised: disallowed HTML stripped from text fields; defaults applied (status=Draft, priority=Medium if not supplied); UTC timestamp and actor ID attached. | Application | XSS sanitisation; audit metadata from authenticated session |
| 6 | Record written to primary database within ACID transaction; unique UUID generated for test case. | Application / DB | Duplicate check; unique constraint enforced; rollback on any failure |
| 7 | Audit log event appended (actor, action=CREATE, resource=test_case, id, diff). | Application | Append-only log; tamper-evident; separate from primary DB write path |
| 8 | Search index update queued asynchronously. | Application (async) | Failure of index update does not roll back or retry the primary write |
| 9 | Notification events queued for configured subscribers (assignees, watchers). | Application (async) | Async delivery; retry on failure; dead-letter queue for persistent failures |
| 10 | API returns HTTP 201 Created with full persisted test case record including generated ID. | API | Response confirms all committed values to client |
4. Flow 3 — Test Run Execution
| # | Activity | Actor / System | Controls Applied |
|---|---|---|---|
| 1 | Test Lead creates a Test Run from a Test Plan, assigning testers. | Test Lead | RBAC: create test run permission; assigned testers must be workspace members |
| 2 | Tester opens assigned run; views test cases and step details. | Tester | Workspace and project scope enforced; only assigned items shown |
| 3 | Tester executes step-by-step; selects result (Pass/Fail/Blocked/Not Run/In Progress) and optionally adds comment per step. | Tester | Enum validation on result value; comment max length; XSS sanitisation |
| 4 | Each step result written transactionally; run completion percentage recomputed atomically. | Application / DB | ACID transaction; audit event logged per step; completion % formula: passed+failed+blocked / total |
| 5 | Tester optionally links a defect to a failing step. | Tester | Defect ID validated against workspace; RBAC to create/link defects checked |
| 6 | On final step submission or explicit ‘Complete Run’ action: run status set to Completed; completion event logged. | Tester / Application | Status transition validated; completion timestamp recorded; notifications triggered |
| 7 | Report aggregates and dashboards updated asynchronously. | Application (async) | Scoped to workspace/project; no cross-tenant data |
5. Flow 4 — AI Test Generation
| # | Activity | Actor / System | Controls Applied |
|---|---|---|---|
| 1 | Authenticated user navigates to AI generation screen within a project. | User | Session + RBAC: AI feature must be enabled for workspace tier |
| 2 | User enters prompt or uploads BRD, Jira story, Figma image, or screenshot. | User | Text: length limit enforced; File: MIME type and size validated before transmission |
| 3 | QA Touch composes structured prompt to LLM provider; workspace context included; no cross-workspace data included in prompt. | Application | Prompt construction uses only authenticated user’s workspace data |
| 4 | HTTPS/TLS 1.3 API request sent to third-party LLM provider. | Application / LLM Provider | TLS 1.3; DPA in place; provider contract prohibits training on customer prompts [VERIFY] |
| 5 | LLM response received; schema validated; malformed responses rejected with error. | Application | Response parsing; fallback error shown to user if malformed |
| 6 | Generated test cases displayed in review interface for user editing. | Application / User | No auto-commit; user must explicitly click Save for each accepted item |
| 7 | User edits, accepts, or discards each item; accepted items saved via standard test case creation flow (Flow 2). | User / Application | Full validation and audit logging of created records |
| 8 | AI request metadata logged: user ID, workspace ID, model identifier, token count, timestamp. | Application | Prompt content retention per AI data policy [VERIFY with engineering] |
6. Flow 5 — Integration Sync (Jira Example)
| # | Activity | Actor / System | Controls Applied |
|---|---|---|---|
| 1 | Admin configures Jira integration: enters Jira URL, OAuth credentials/PAT, and project field mappings. | Admin / Application | Credentials encrypted and stored in secrets manager; admin RBAC enforced |
| 2 | QA Touch registers a webhook in Jira to receive issue event notifications. | Application / Jira | Webhook secret generated; HMAC-SHA256 validation configured |
| 3 | Defect created in QA Touch; integration maps fields per configuration; Jira API called to create linked issue. | Application / Jira API | Field mapping validated; OAuth token used; TLS enforced; API response validated |
| 4 | Jira sends webhook event to QA Touch on issue status change. | Jira / Application | HMAC signature validated; event type checked against whitelist; queued for processing |
| 5 | QA Touch updates linked defect status; idempotent processing ensures no duplicates. | Application / DB | Duplicate event ID check; audit event logged; sync outcome recorded |
| 6 | On sync failure: retry (3 attempts, exponential backoff); persistent failure alerts admin. | Application | Dead-letter queue; admin notification; retry log maintained |