System Input Control 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 policy defines the controls applied to all system inputs accepted by QA Touch to ensure completeness, accuracy, and integrity of data entering the platform. It supports SOC 2 Processing Integrity criteria PI1.2 (Completeness) and PI1.3 (Accuracy), requiring that all inputs are complete, accurate, and authorised before processing begins.

This policy applies to all data entry mechanisms: the web application UI, REST API, file imports (Excel/CSV), webhook inbound payloads, and integration sync events from third-party systems.

2. Input Control Principles

Principle	Definition and Application in QA Touch
Authorization	Only authenticated and properly authorised users or systems may submit inputs. Authentication validated on every request; RBAC checked per operation.
Completeness	Required fields must be present and non-empty before a record is accepted. Absence of mandatory fields results in a rejection response with field-level detail.
Accuracy	Input values must conform to defined data types, formats, enumerations, and business rules. Validation is enforced at the server side regardless of client-side checks.
Server-Side Primacy	Server-side validation is the authoritative and mandatory layer. Client-side validation improves UX but cannot be bypassed to circumvent server-side rules.
Non-Repudiation	All input events are associated with an authenticated user or service identity and recorded in the audit log.
Reject-on-Failure	Invalid or unauthorised inputs are rejected with a structured error response. Inputs are never silently discarded or partially committed.
Idempotency	Critical write operations support idempotency keys to prevent duplicate submission on network retry.

3. Input Sources and Control Matrix

Input Source	Authentication	Authorization	Validation Applied
Web UI (User)	Session token (HttpOnly cookie)	RBAC role/permission check per action	Client-side + server-side field validation; CSRF token required
REST API (API Key)	API key in Authorization header	Scope-based permission check	Server-side JSON schema validation; rate limiting applied
REST API (OAuth 2.0)	OAuth 2.0 Bearer token	OAuth scope + RBAC check	Server-side JSON schema validation; rate limiting applied
Excel / CSV Import	Authenticated user session	RBAC: import permission required	File type, size, column headers, row-level field and type validation
Webhook Inbound (CI/CD, integrations)	HMAC-SHA256 signature validation	Pre-registered endpoint whitelist; event type whitelist	Payload schema validation; unknown event types rejected
Integration Sync (Jira, ADO, etc.)	OAuth token per integration config	Workspace-scoped integration configuration	Field mapping validation; type coercion; unmapped fields logged
Internal Admin API	Service account credentials + IP allowlist	Service account RBAC	Full schema validation + business rule enforcement

4. Server-Side Validation Controls (Mandatory)

4.1 Field-Level Validation

• Type validation: each field validated against its declared type (string, integer, boolean, date, UUID, enum).
• Required fields: HTTP 422 Unprocessable Entity returned with field-level error detail if any required field is absent.
• Maximum and minimum length enforced for all string fields.
• Enum fields: only values within the defined set accepted; all others rejected with explicit error naming permitted values.
• Format validation: dates must conform to ISO 8601; email addresses to RFC 5322 pattern; UUIDs to v4 format.

4.2 Business Rule Validation

• Cross-field consistency rules enforced (e.g., test run end date must be after start date; referenced project must be in same workspace).
• Referential integrity: foreign key references validated against existing records within the same workspace before commit.
• Workspace scoping: all records can only reference entities within the same workspace; cross-workspace references rejected.

4.3 Security-Oriented Input Controls

• SQL injection prevention: parameterised queries and ORM layer enforced for all database operations; no raw string concatenation in queries.
• XSS prevention: all user-supplied text fields sanitised against an allowlist HTML sanitiser on output; script injection rejected.
• CSRF protection: all state-changing web UI requests require a valid CSRF token validated server-side.
• File upload validation: MIME type, file extension, and maximum size enforced; file content integrity checked before storage.
• Request size limits enforced to prevent payload flooding (assumption: 10 MB max request body [VERIFY]).

5. Import File Input Controls

• Only .xlsx and .csv file types accepted; other MIME types rejected immediately.
• Maximum import file size enforced (assumption: 10 MB [VERIFY]).
• Column headers validated against the expected template schema; unknown columns flagged as warnings.
• Row-level validation: each row evaluated independently; invalid rows reported with row number and rejection reason; valid rows continue processing.
• Import aborts if error rate exceeds threshold (assumption: >20% invalid rows [VERIFY]); full import error report provided to user.
• Duplicate detection: records with matching unique identifiers flagged for user review before commit.

6. Error Handling and Audit

• All rejected inputs receive a structured JSON error response: HTTP status code, error code, field name, and human-readable message.
• Error messages are informative about the validation failure but do not expose internal system architecture, database schemas, or stack traces.
• All input validation failures are logged with: source (UI/API/import/webhook), user/system identity, timestamp, endpoint, and error detail.
• Repeated validation failures from the same source IP or API key trigger an automated security alert (brute-force / fuzzing detection threshold).