Data Storage 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 how inputs, items in processing, and outputs are stored within QA Touch, including criteria for accuracy, completeness, and timeliness, and ensuring alignment with system and security specifications. Supports SOC 2 Processing Integrity (PI1) and Confidentiality (C1) criteria.
2. Storage Architecture Overview
| Storage Layer | Technology [VERIFY] | Data Stored | Encryption |
|---|---|---|---|
| Primary Relational Database | PostgreSQL (managed RDS / Cloud SQL) | All workspace, project, test case, run, defect, user, audit, and integration data | AES-256 at rest; TLS 1.2+ in transit |
| Object Storage | AWS S3 / GCP Cloud Storage | File attachments, import uploads, export packages, generated report files | AES-256 SSE; public access blocked; versioning enabled |
| Cache (ephemeral) | Redis | Session tokens, rate limit counters, short-lived UI state | TLS in transit; ephemeral — no persistence [VERIFY] |
| Search Index | Elasticsearch / OpenSearch | Indexed test case and defect text for full-text search | AES-256 at rest; TLS in transit |
| Log Store / SIEM | Datadog / Splunk / CloudWatch | Application logs, security events, access logs, audit events | Provider-managed encryption; TLS in transit |
| Secrets Store | HashiCorp Vault / AWS Secrets Manager | Integration credentials, internal service secrets, API keys (metadata only) | AES-256-GCM; cloud KMS-managed key |
| Backup Storage | Cloud provider snapshots + archive tier | Full database snapshots; object storage versioning for file attachments | AES-256; same KMS key hierarchy as primary storage |
3. Data Accuracy and Completeness Controls
- ACID transactions: all write operations to the primary database are wrapped in transactions; any failure causes a full rollback — partial writes are never committed.
- Referential integrity: foreign key constraints enforced at the database layer; orphaned records prevented by cascading delete or restrict rules.
- Unique constraints: key identifiers (workspace ID, user email, test case ID) are enforced as unique at the database layer.
- Non-null constraints: mandatory fields enforced at the database layer as a secondary control behind application-layer validation.
- Backup integrity verification: checksums computed on backup completion; restore tests confirm data integrity matches pre-backup state.
- Audit log integrity: audit records are append-only; cryptographic hash-chaining or equivalent tamper-evidence mechanism applied [VERIFY implementation].
4. Storage Timeliness Controls
- Write confirmation: API returns the fully persisted record in the response; clients can confirm committed field values.
- Replication lag monitoring: if multi-AZ or multi-region replication is used, replication lag is monitored and alerted when exceeding defined threshold.
- Async job monitoring: background jobs (search indexing, notification delivery, export generation) monitored; backlogs trigger operational alerts.
- Backup timeliness: daily backup completion verified by 06:00 UTC; failure triggers immediate P2 alert.
5. Staging and Transient Storage
| Transient Data Type | Staging Storage | Deletion Trigger |
|---|---|---|
| Import upload file | Isolated temporary path in object storage per import job; not accessible to other users or workspaces | Immediately on import completion or failure; maximum 24-hour TTL enforced by lifecycle policy |
| Export generated file | Object storage with time-limited pre-signed URL | 24–72 hours after generation; immediately invalidated on first access [VERIFY] |
| AI prompt / file (input) | Transmitted to LLM provider; not stored in QA Touch DB beyond session unless retention configured [VERIFY] | Per AI data retention policy [VERIFY with engineering] |
| Session tokens | Redis cache (ephemeral) | On explicit logout; idle timeout (30 min); absolute expiry (24h); account deactivation |
| Password reset tokens | Primary database (hashed) | On first use; 60-minute TTL enforced |
| Webhook inbound payload | Processing queue (async); not persistently stored after processing | Immediately after processing completes; delivery log retained separately for 90 days |
6. Multi-Tenant Storage Isolation
- All database records include a workspace_id column; all application queries mandatory-scope to the authenticated workspace’s ID.
- ORM / query builder layer enforces workspace scoping; raw database queries are prohibited in application code without explicit security review.
- Object storage: each workspace’s files stored under a workspace-specific path prefix; IAM bucket policies restrict access to matching prefix only.
- Any attempt to query across workspace boundaries is logged as a security event and triggers an alert.
- Cross-tenant access prohibition tested as part of the regression security test suite on every release.