Data Classification Policy

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

Data Definition and Classification Policy

1. Purpose and Scope

1.1 Purpose

This Data Definition and Classification Policy establishes a formal framework for identifying, categorizing, protecting, and managing all data assets processed, stored, or transmitted by QA Touch. The policy ensures that data handling practices align with the Trust Service Criteria (TSC) for Security (CC6), Availability (A1), Confidentiality (C1), and Privacy (P1–P8) as defined by the American Institute of Certified Public Accountants (AICPA) for SOC 2 Type II engagements.

Specifically, this document enables QA Touch to:

Define and catalogue all data elements within the platform environment.
Apply consistent classification labels that drive security and access control decisions.
Demonstrate to auditors that data protection controls are commensurate with data sensitivity.
Provide data owners, engineers, and compliance personnel with actionable guidance.
Support incident response, business continuity, and vendor risk management programs.

1.2 Scope

This policy applies to:

All customer data ingested, generated, stored, or processed within the QA Touch SaaS platform (production, staging, and development environments where applicable).
All QA Touch employees, contractors, and third-party service providers with access to covered data.
All systems, services, and integrations that host or transmit QA Touch or customer data, including cloud infrastructure, APIs, and third-party connectors.
AI-powered features that process customer-supplied prompts or artifacts to generate test assets.

NOTE: This policy does not extend to customer-owned production application data unless explicitly imported into QA Touch by the customer through a supported integration or import workflow.

2. Data Categories and Elements

2.1 Overview of Data Categories

QA Touch processes and stores data across seven primary categories. Each category is described below with its constituent data elements, primary source, and classification level.

Category 1: User Account and Identity Data

Data Element	Description	Source	Classification
Full Name	User’s first and last name as provided at registration	User Registration	Confidential
Email Address	Primary login identifier and notification destination	User Registration / SSO	Confidential
Password Hash	Bcrypt/Argon2 hashed credential; plaintext never stored	User Registration	Restricted
Phone Number	Optional MFA/notification channel	User Profile	Confidential
Profile Photo	Optional avatar uploaded by user	User Profile	Internal
Role & Permissions	RBAC role assignments within workspaces	Admin Configuration	Internal
SSO / OAuth Tokens	Third-party identity provider tokens for federated login	Identity Provider	Restricted
MFA Secrets / Recovery Codes	TOTP secrets and one-time recovery codes	Authentication Service	Restricted
Login Timestamps	Record of authentication events with IP and device info	Application Logs	Internal
Session Tokens	Short-lived tokens granting authenticated session access	Authentication Service	Restricted
API Keys	Long-lived tokens enabling programmatic access to platform APIs	User/Admin Generated	Restricted

Category 2: Workspace and Organization Data

Data Element	Description	Source	Classification
Workspace Name	Organization/tenant display name	Admin Setup	Internal
Workspace ID / Slug	Unique system identifier for tenant isolation	System Generated	Internal
Billing Information	Payment method, subscription tier, invoice history	Payment Processor	Restricted
License / Seat Count	Number of licensed user seats and active users	Admin Console	Confidential
Custom Domain Settings	Subdomain or SSO domain configurations	Admin Configuration	Internal
Workspace Settings	Feature flags, notification preferences, integrations enabled	Admin Configuration	Internal
Subscription Metadata	Plan type, renewal dates, trial status	Billing System	Confidential

Category 3: Project and Testing Artifact Data

Data Element	Description	Source	Classification
Projects	Project names, descriptions, status, metadata	User Created	Confidential
Test Cases	Test case titles, steps, expected results, preconditions	User Created	Confidential
Test Suites	Logical groupings of test cases	User Created	Confidential
Reusable Test Steps	Shared step libraries referenced across test cases	User Created	Confidential
Test Plans	Configurations defining scope and execution strategy	User Created	Confidential
Test Runs / Executions	Execution results, pass/fail status, comments per step	User/System Generated	Confidential
Defects / Bug Reports	Defect descriptions, severity, status, attachments	User Created	Confidential
Requirements	Business or functional requirements linked to test cases	User Created / Imported	Confidential
Milestones	Project milestones with dates and linked items	User Created	Confidential
Custom Fields	User-defined metadata fields and their values	Admin/User Configuration	Confidential
Attachments	Screenshots, files, logs uploaded to test items	User Uploaded	Confidential
Comments	Free-text comments on test cases, runs, defects	User Created	Confidential
Reports / Dashboards	Generated summary and trend reports	System Generated	Confidential

Category 4: Integration and Configuration Data

Data Element	Description	Source	Classification
Integration Credentials	OAuth tokens, PATs, API keys for Jira, Azure DevOps, GitHub, GitLab, Bitbucket, Slack, etc.	User/Admin Configured	Restricted
Webhook Configurations	Endpoint URLs, secrets, and event trigger settings	User/Admin Configured	Restricted
CI/CD Pipeline Settings	Pipeline identifiers and trigger configurations	User/Admin Configured	Confidential
Issue Tracker Mappings	Field mappings between QA Touch and external systems	User Configured	Confidential
Synced Issue Metadata	Titles, descriptions, statuses of synced external issues	External Integration	Confidential
Automation Framework Config	Framework type and execution endpoint settings	User Configured	Confidential

Category 5: Audit, Logging, and Observability Data

Data Element	Description	Source	Classification
Audit Logs	User actions with actor, timestamp, resource, and change detail	System Generated	Internal
Application Logs	Error messages, stack traces, performance events	System Generated	Internal
Security Event Logs	Login attempts, MFA events, permission changes, API key usage	System Generated	Restricted
Infrastructure Metrics	CPU, memory, latency, uptime data	Cloud Provider	Internal
Access Logs	HTTP request logs with endpoint, status, IP, user-agent	System Generated	Internal
Backup Logs	Timestamps and success/failure of backup operations	System Generated	Internal

Category 6: AI Feature Data

ASSUMPTION: QA Touch routes AI generation requests to a third-party LLM provider (e.g., OpenAI or Anthropic). Verify: (a) which provider(s) are used, (b) whether a data processing agreement (DPA) is in place, (c) whether prompts are used to train provider models, and (d) retention policies for prompt/response data on the provider side.

Data Element	Description	Source	Classification
AI Prompts	Natural language input from user, including pasted BRDs, Jira stories, feature descriptions, and scenario text	User Provided	Confidential
Uploaded Artifacts for AI	Figma/mockup images, screenshots, and document files submitted for AI test generation	User Uploaded	Confidential
AI-Generated Outputs	Test cases, BDD scenarios, and test steps generated by the AI model	AI Service Generated	Confidential
BDD Scenarios (Input)	Gherkin or natural language BDD scenarios provided as input	User Provided	Confidential
AI Request Metadata	Timestamps, user ID, workspace ID, model used, token counts	System Generated	Internal
Jira Story Content (AI Input)	Story titles, descriptions, and acceptance criteria imported for AI generation	External Integration	Confidential

Category 7: Import/Export and Transient Data

Data Element	Description	Source	Classification
Excel/CSV Import Files	Uploaded files containing test case or requirement data	User Uploaded	Confidential
Exported Test Assets	Generated Excel, CSV, or PDF export packages	System Generated	Confidential
Temporary Import Staging	Intermediate parsed records prior to validation and commit	System Generated	Confidential
Error Reports from Import	Row-level validation error messages shown to users	System Generated	Internal

3. Data Classification Framework

QA Touch employs a four-tier data classification model. Each tier carries mandatory handling, encryption, access, and retention requirements. Classification is assigned by the Data Owner and reviewed annually or upon material change.

Level	Label	Definition	Examples in QA Touch
PUBLIC	Publicly available information with no restriction on disclosure.	Information intended for public consumption. No harm if disclosed.	Marketing materials, public documentation, status page, feature announcements.
INTERNAL	Non-public information intended for employees and authorized contractors only.	Unauthorized disclosure causes limited harm but violates acceptable use policies.	Audit logs, access logs, workspace settings, role assignments, infrastructure metrics.
CONFIDENTIAL	Sensitive customer or business data requiring strict access controls.	Unauthorized disclosure causes significant harm, regulatory exposure, or breach of contract.	Test cases, defects, requirements, user names, email addresses, AI prompts, subscription data, import files.
RESTRICTED	Highest sensitivity. Credentials, secrets, and regulated personal data.	Unauthorized disclosure results in immediate and severe harm, regulatory penalty, or breach of trust.	Password hashes, MFA secrets, SSO tokens, integration credentials (OAuth tokens, PATs), API keys, billing payment data, session tokens.

4. Data Owners

A Data Owner is a senior organizational role responsible for approving classification changes, authorizing access, and ensuring data handling requirements are met. Data Stewards perform day-to-day operational responsibilities on behalf of the Owner.

ASSUMPTION: The specific owner roles below are representative. QA Touch should verify and update these assignments to reflect actual organizational structure before presenting to auditors.

Data Category	Data Owner (Role)	Data Steward (Role)	Responsibilities
User Account & Identity Data	Chief Information Security Officer (CISO)	Identity & Access Management Lead	Classify, control access, approve retention schedules, manage breach response.
Workspace & Organization Data	VP of Engineering	Database Administrator	Enforce logical tenant isolation, approve backup schedules, manage deletion upon offboarding.
Project & Testing Artifacts	VP of Product	Platform Engineering Lead	Define retention rules, approve export controls, review data quality standards.
Integration & Configuration Data	VP of Engineering	Security Engineer	Manage credential rotation policies, approve third-party integrations, oversee webhook security.
Audit & Logging Data	CISO	DevOps/SRE Lead	Define retention periods, manage log access, ensure log integrity and tamper-evidence.
AI Feature Data	Chief Product Officer (CPO)	AI Engineering Lead	Review DPAs with AI providers, control what data is sent to AI APIs, manage prompt retention.
Import/Export Transient Data	VP of Engineering	Platform Engineering Lead	Define staging retention windows, ensure secure deletion of temporary files post-processing.
Billing & Payment Data	Chief Financial Officer (CFO)	Finance/Operations Lead	Manage PCI DSS scope, oversee tokenization, approve access to billing records.

5. Data Lifecycle

5.1 Collection

QA Touch collects data through the following mechanisms:

Direct user input via the web application interface (test case creation, project setup, defect logging).
Self-service registration and profile management forms.
File uploads (Excel, CSV, screenshots, attachments, Figma files) via Import screens and AI feature pages.
OAuth and API-based integrations with Jira, Azure DevOps, GitHub, GitLab, Bitbucket, Slack, and CI/CD pipelines.
AI prompt submissions by users through the AI test generation feature.
REST API and webhook callbacks from external systems.
Infrastructure and application telemetry collected automatically by the QA Touch platform.

NOTE: QA Touch does not collect or process End User (customer’s customer) personal data from the customer’s production applications unless the customer explicitly imports or syncs such data through a supported integration.

5.2 Storage

Data is stored in the following system layers:

Storage Layer	Technology	Data Types Stored	Classification Level
Primary Relational Database	PostgreSQL (cloud-managed, e.g., AWS RDS or GCP Cloud SQL)	All customer workspace data, user accounts, audit logs	Confidential / Restricted
Object Storage	AWS S3 or GCP Cloud Storage	File attachments, screenshots, export packages, import uploads	Confidential
Caching Layer	Redis (ephemeral)	Session tokens, short-lived UI state, rate limit counters	Restricted (transient)
Log Aggregation	SIEM / log management platform (e.g., Datadog, Splunk)	Application logs, security events, access logs	Internal / Restricted
Key Management	Cloud KMS (e.g., AWS KMS, GCP Cloud KMS)	Encryption keys and secrets	Restricted
Secrets Management	HashiCorp Vault or AWS Secrets Manager	Integration credentials, internal service secrets	Restricted
Search Index	Elasticsearch / OpenSearch (if applicable)	Indexed test case and defect content	Confidential

ASSUMPTION: Technology stack assumptions above are illustrative. Verify the actual database engine, cloud provider, caching technology, and SIEM platform with the QA Touch engineering team.

5.3 Processing

Data processing activities include:

CRUD operations performed via the application tier in response to authenticated API requests.
AI test generation: user-submitted prompts and artifacts are transmitted to a third-party AI API, processed, and the resulting test case output is returned and optionally persisted in the workspace.
Import processing: uploaded Excel/CSV files are parsed, validated, and transformed into test case records; temporary staging data is deleted upon completion.
Report generation: aggregated and anonymized metrics are computed across test run execution data.
Integration synchronization: bidirectional data exchange with Jira, Azure DevOps, and other systems through scheduled or event-driven sync processes.

Customer data is shared only in the following circumstances:

With authorized users within the same customer workspace (enforced by RBAC).
With third-party sub-processors listed in Section 9 under Data Processing Agreements (DPAs).
With external systems explicitly configured by the customer through Integration settings (Jira, Slack, etc.).
With authorized QA Touch personnel for support, debugging, or security incident response, subject to internal access controls and audit logging.
As legally required by applicable law or valid legal process, following QA Touch’s Law Enforcement Request Policy.

IMPORTANT: Customer data is never sold, rented, or shared with third parties for advertising or marketing purposes.

5.5 Archival

Archival is performed for data that has passed its active operational period but is subject to retention requirements for legal, compliance, or support purposes:

Audit logs are retained in a read-only archive tier after the active log window expires.
Deleted workspace data may be retained in encrypted backups for up to 30 days before permanent removal.
Export packages generated by users are retained for a limited window (assumption: 24–72 hours) in object storage before automatic deletion.

ASSUMPTION: Confirm archival periods and archive storage class (e.g., AWS S3 Glacier) with the engineering team.

5.6 Deletion

Data deletion is triggered by:

User or admin deletion of specific records within the platform (test cases, defects, attachments).
Workspace deactivation or subscription termination: all workspace data is scheduled for deletion within 30 days of contract end (assumption), with confirmation to the customer.
Retention period expiry: automated processes purge data that has exceeded defined retention thresholds.
Data Subject Requests (DSRs): upon verified request, personal data is deleted or anonymized within the timeframe specified in the Privacy Policy and applicable regulation.

ASSUMPTION: The specific offboarding data deletion timeline (e.g., 30 days) should be confirmed with QA Touch legal and engineering teams and referenced in customer contracts and the Privacy Policy.

6. Data Quality Criteria

QA Touch maintains data quality across the following dimensions to ensure the accuracy and reliability of customer testing workflows and platform reporting:

Dimension	Criteria and Standard	Control Mechanism
Accuracy	Data values reflect true user intent and match the source system of record.	Input validation rules; type enforcement at API layer; integration field mapping validation.
Completeness	Mandatory fields (e.g., test case title, step description) are populated before record creation.	Required field constraints enforced at API and UI layers; import row-level validation with error reporting.
Consistency	Data is uniform across related records (e.g., test run status consistent with linked test case steps).	Referential integrity enforced at the database layer; transactional writes for linked record updates.
Timeliness	Data is available for user access within acceptable latency SLAs.	Database indexing; caching; uptime and performance monitoring with alerting thresholds.
Uniqueness	Duplicate records are prevented at the workspace and project scope.	Unique constraints on key identifiers (workspace ID, test case ID); deduplication checks during import.
Integrity	Data is protected from unauthorized modification or corruption at rest and in transit.	Encryption at rest and in transit; checksum validation on backups; tamper-evident audit logs.
Availability	Data is accessible to authorized users in accordance with uptime commitments.	Multi-AZ deployment; automated failover; backup and restoration testing; incident response procedures.

7. Data Retention Guidelines

ASSUMPTION: Retention periods below are representative and based on common SaaS practices. QA Touch legal and engineering teams must confirm and formalize these periods in a binding Retention Schedule.

Data Type	Active Retention	Archive Retention	Deletion Trigger	Legal Basis
User Account Data	Duration of account	90 days post-closure	Account deletion or workspace offboarding	Contractual obligation; GDPR Art. 17
Workspace / Project Data	Duration of subscription	30 days post-termination	Subscription end + 30 days	Customer contract
Test Cases, Runs, Defects	Duration of project lifecycle	Included in workspace retention	Project or workspace deletion	Customer contract
Audit Logs	12 months active	24 months archive	36 months from creation	SOC 2 audit evidence; contractual
Security Event Logs	12 months active	24 months archive	36 months from creation	SOC 2 CC7; GDPR Art. 5(1)(e)
Application Logs	30 days active	90 days archive	90 days from creation	Operational necessity
AI Prompts & Outputs	Duration of workspace	N/A (deleted with workspace)	Workspace deletion	Customer contract; minimization principle
Integration Credentials	Duration of active integration	N/A	Integration removed by admin	Security best practice
Backup Snapshots	7 daily, 4 weekly, 12 monthly	N/A	Automated rotation per schedule	Availability commitments
Import Staging Files	Processing duration only	N/A	Immediate on completion or failure	Data minimization
Export Packages	24–72 hours	N/A	Automated TTL expiry	Data minimization
Billing / Payment Records	Duration of subscription	7 years post-termination	Legal hold expiry	Tax law; PCI DSS
Session Tokens	Session duration (e.g., 24h)	N/A	Expiry or explicit logout	Security necessity

8. Security Controls by Data Classification

The following controls apply to each classification tier. Higher classifications inherit all controls from lower tiers.

8.1 PUBLIC Data Controls

No access restrictions required for read access.
Write access restricted to authorized QA Touch marketing and documentation teams.
Content reviewed and approved before publication.

8.2 INTERNAL Data Controls

Access restricted to authenticated QA Touch employees and authorized contractors.
Transmitted over TLS 1.2 or higher in all internal and external communications.
Stored with encryption at rest using AES-256 or equivalent.
Access logged in the SIEM; anomalous access reviewed quarterly.
Shared via approved internal tools only (not personal email or unauthorized cloud storage).

8.3 CONFIDENTIAL Data Controls

All INTERNAL controls apply.
Access granted on a least-privilege, need-to-know basis; reviewed quarterly by data owners.
Logical tenant isolation enforced: workspace A cannot access workspace B data under any circumstances.
Encrypted at rest with AES-256; encryption keys managed by cloud KMS with annual rotation.
Customer data accessed by QA Touch support staff only with documented customer authorization or in response to a declared security incident.
All access by QA Touch personnel logged with tamper-evident audit trail.
Export and download events logged with user identity, timestamp, and record scope.
Vulnerability scanning and penetration testing performed at least annually; findings remediated per SLA.

8.4 RESTRICTED Data Controls

All CONFIDENTIAL controls apply.
Access limited to specific named roles with documented authorization from the CISO or Data Owner.
Multi-factor authentication (MFA) enforced for all accounts with access to Restricted data.
Credentials (API keys, OAuth tokens, MFA secrets) stored only in approved secrets management systems; never in source code, configuration files, or logs.
Secrets rotated at least every 90 days or immediately upon suspected compromise.
Password hashes stored using adaptive hashing algorithms (e.g., Argon2id or bcrypt with cost factor ≥12).
Session tokens expire after maximum 24 hours (assumption); sliding expiry enforced.
Billing payment data handled through PCI-compliant payment processor; raw card data never stored in QA Touch systems.
Access attempts to Restricted resources generate real-time security alerts.

ASSUMPTION: MFA enforcement, session expiry settings, password hashing algorithm, and secrets rotation schedules require verification with QA Touch security engineering.

9. Third-Party Systems

The following categories of third-party systems receive or provide data to QA Touch. A Data Processing Agreement (DPA) or equivalent contractual instrument must be in place for each sub-processor handling personal data or Confidential/Restricted information.

ASSUMPTION: Specific vendor names marked [VERIFY] must be confirmed with QA Touch engineering and procurement. The DPA column reflects expected status; actual agreement status must be verified.

Category	Example Vendor(s)	Data Shared	Purpose	DPA Required
Cloud Infrastructure	AWS / GCP / Azure [VERIFY]	All platform data (host)	Compute, storage, networking, managed database services	Yes — MSA / DPA in place
AI / LLM Provider	OpenAI / Anthropic [VERIFY]	AI prompts, uploaded artifacts	Generate test cases and BDD scenarios from user input	Yes — Critical DPA required
Payment Processor	Stripe / Braintree [VERIFY]	Payment method data, invoice metadata	Subscription billing, payment processing	Yes — PCI DSS SAQ required
Identity / SSO Provider	Auth0 / Okta / Google Workspace [VERIFY]	Email, SSO tokens	Federated authentication and MFA	Yes — DPA required
Email Delivery	SendGrid / SES / Postmark [VERIFY]	User email addresses, notification content	Transactional email (invites, alerts, reports)	Yes — DPA required
Monitoring & SIEM	Datadog / Splunk / Cloudwatch [VERIFY]	Application logs, metrics, security events	Observability, alerting, audit log storage	Yes — DPA required
Error Tracking	Sentry / Rollbar [VERIFY]	Stack traces, partial request context	Application error monitoring and debugging	Yes — data minimization required
Customer Support	Intercom / Zendesk [VERIFY]	User email, support conversation content	Customer support ticket management	Yes — DPA required
Issue Trackers (Integration)	Jira, Azure DevOps, GitHub, GitLab, Bitbucket	Issue metadata, defect data, synced records	Bidirectional integration configured by customer	Customer responsibility; QA Touch acts as processor
Communication (Integration)	Slack	Notification payloads (project/test status)	Notification delivery configured by customer	Customer responsibility; QA Touch acts as processor
Source Control (Integration)	GitHub, GitLab, Bitbucket	Repository event webhooks	CI/CD trigger integration configured by customer	Customer responsibility
CDN / WAF	Cloudflare / AWS CloudFront [VERIFY]	HTTP request metadata, user IP addresses	Content delivery, DDoS protection, WAF	Yes — DPA required

10. Encryption Requirements

10.1 Encryption at Rest

All data classified as Internal, Confidential, or Restricted must be encrypted at rest using the following standards:

Storage System	Algorithm	Key Length	Key Management	Rotation
Primary Database (PostgreSQL)	AES-256-GCM	256-bit	Cloud KMS (platform-managed)	Annual or on compromise
Object Storage (S3/GCS)	AES-256-SSE	256-bit	Cloud KMS with customer-managed key option [VERIFY]	Annual
Backup Snapshots	AES-256	256-bit	Cloud KMS	Per backup rotation schedule
Log Archives	AES-256	256-bit	Cloud KMS	Annual
Secrets at rest (Vault/Secrets Manager)	AES-256-GCM	256-bit	Dedicated secrets manager	On access or annual
Redis Cache	AES-256 (if persistent)	256-bit	Cloud provider managed	Annual

10.2 Encryption in Transit

Data Flow	Protocol	Min. TLS Version	Certificate Management	Cipher Suite Policy
Browser to QA Touch Application	HTTPS / TLS	TLS 1.2 (TLS 1.3 preferred)	Automated via Let’s Encrypt or ACM	Forward secrecy required; SSLv3, TLS 1.0, 1.1 disabled
Application to Database	TLS	TLS 1.2+	Cloud-managed certificates	Forward secrecy required
Application to AI API Provider	HTTPS / TLS 1.3	TLS 1.2+	Provider-managed (HSTS enforced)	Forward secrecy required
Application to Integration APIs (Jira, etc.)	HTTPS / TLS	TLS 1.2+	Provider certificates; validated	Verify against CA store
Intra-service communication (microservices)	mTLS [VERIFY]	TLS 1.2+	Internal PKI / service mesh	Forward secrecy required
Application to Object Storage	HTTPS / TLS	TLS 1.2+	Cloud-managed	Forward secrecy required
Webhook delivery to customer endpoints	HTTPS only	TLS 1.2+	Customer-owned certificate	HMAC signature validation on payload
Email delivery (SMTP)	STARTTLS / TLS	TLS 1.2+	Provider-managed	Opportunistic TLS; DKIM, SPF, DMARC enforced

ASSUMPTION: TLS termination approach (e.g., at load balancer or end-to-end), certificate authority, and mTLS adoption for internal services should be confirmed with the QA Touch infrastructure team.

11. Access Control Requirements

11.1 Principle of Least Privilege

All access to QA Touch systems, customer data, and platform infrastructure is governed by the principle of least privilege. Users, services, and systems are granted only the minimum access necessary to perform their defined function.

11.2 Role-Based Access Control (RBAC) — Customer Workspace

Within each customer workspace, QA Touch enforces role-based access control with the following standard role tiers:

Role	Permissions	Data Access Scope
Owner / Admin	Full workspace management: user provisioning, integration config, billing, project creation, all CRUD operations.	All data within the workspace.
Project Manager	Create and manage projects, test plans, milestones; assign users; view reports.	All data within assigned projects.
Test Lead / Senior Tester	Create and manage test cases, suites, runs, defects; review and approve test plans.	All data within assigned projects.
Tester	Execute test runs, log results and defects, upload attachments, view assigned test cases.	Assigned test cases, runs, defects.
Viewer / Read-Only	View test cases, runs, reports, and dashboards; cannot create or modify records.	Read-only access to assigned project data.
API User	Programmatic access via API key scoped to authorized operations.	Scoped per API key permissions configured by admin.

11.3 QA Touch Internal Access Controls

QA Touch personnel access to production systems and customer data is governed by the following controls:

Production database and infrastructure access is restricted to the Engineering/DevOps team and requires VPN + MFA authentication.
Support personnel access customer workspaces only upon documented customer authorization or declared incident; all access is logged.
Access rights are reviewed quarterly by the CISO and revoked immediately upon employee termination (SLA: within 1 business day).
Privileged access management (PAM) solution controls and audits all privileged sessions (assumption).
Shared credentials are prohibited; all personnel use individually attributed accounts.
Break-glass (emergency) access procedures require dual authorization and generate an automatic security alert.

11.4 Authentication Standards

All customer accounts: username/password with option to enforce SSO via SAML 2.0 or OIDC.
MFA enforcement: available to all users; enforceable by workspace admins; required for Restricted data access.
Password policy (assumption): minimum 12 characters, complexity requirements, breach-password checking via Have I Been Pwned API or equivalent.
Session management: idle session timeout after 30 minutes (assumption); absolute session expiry at 24 hours.
API keys: scoped permissions, rotation capability, and instant revocation by admin.

12. Monitoring and Audit Logging Requirements

12.1 Audit Log Coverage

QA Touch maintains comprehensive audit logs that capture the following event categories:

Event Category	Examples	Captured Attributes	Retention
Authentication Events	Login success/failure, logout, MFA enrollment, MFA failure, password reset, SSO events	User ID, email, IP address, user-agent, timestamp, outcome	36 months
Authorization Events	Access denied, privilege escalation attempt, role change	User ID, resource, action, outcome, timestamp	36 months
Data Modification Events	Create, update, delete on test cases, projects, runs, defects, requirements	User ID, resource type, resource ID, before/after diff, timestamp	36 months
Admin Actions	User provisioning/deprovisioning, role assignment, integration configuration, API key creation/revocation	Admin user ID, action, target user/resource, timestamp	36 months
API Access Events	All API requests with key or token authentication	API key ID, endpoint, method, status code, IP, timestamp	12 months
Export/Download Events	Data export triggered, file downloaded	User ID, workspace, export scope, timestamp, file size	36 months
Integration Events	Integration connected/disconnected, sync triggered, webhook delivery	Integration type, admin user, timestamp, outcome	12 months
AI Feature Events	AI generation request submitted, output returned	User ID, workspace, prompt token count (not content), model, timestamp	12 months
Security Events	Suspicious login, brute force detection, rate limit breach, unauthorized data access attempt	Event type, source IP, user (if known), timestamp, severity	36 months
Infrastructure Events	Deployment, configuration change, backup success/failure, certificate renewal	Actor (system/human), resource, change detail, timestamp	12 months

12.2 Log Integrity and Protection

Audit logs are written to an append-only, tamper-evident log store; no user or application account has delete privileges on production logs.
Log integrity is verified through cryptographic checksums or hash-chaining (assumption).
Logs are shipped in real-time to a centralized SIEM platform separate from the application database.
Access to raw logs is restricted to the Security and Engineering teams; customer-facing audit history is a filtered subset.

12.3 Alerting and Continuous Monitoring

Automated alerts are triggered for: repeated authentication failures (brute force), access from new geographies, privilege escalation, mass data export, and unauthorized API usage.
Security alerts are routed to the on-call security team with defined SLA for triage: Critical = 1 hour, High = 4 hours, Medium = 24 hours.
Availability and performance monitoring with PagerDuty-equivalent alerting for SLA breach conditions.
Vulnerability scanning (DAST and dependency scanning) runs on every deployment pipeline; critical findings block deployment.

12.4 Customer-Facing Audit History

Within the QA Touch application, workspace administrators have access to an Activity Log that records user actions within their workspace. This log includes actor, action type, resource, timestamp, and source IP, but does not expose QA Touch internal system logs or cross-workspace data.

13. Employee Responsibilities

13.1 All Employees

Complete data classification and security awareness training upon onboarding and annually thereafter.
Handle all customer data in accordance with the classification level assigned to that data.
Report suspected data breaches, unauthorized access, or policy violations to the Security team immediately.
Never access customer data outside of documented, authorized support or engineering workflows.
Use only company-approved devices and tools to access production systems.
Never store Confidential or Restricted data on personal devices or unauthorized cloud storage services.

13.2 Engineering Team

Implement data classification controls in application code according to this policy.
Ensure encryption is applied at the storage and transport layers as defined in Section 10.
Review data handling in new features during design review; document data flows in architecture diagrams.
Perform threat modeling for features that introduce new data types or third-party integrations.
Never log Restricted data (credentials, tokens, payment data) in application logs; implement log scrubbing for Confidential data where feasible.
Conduct dependency vulnerability scanning and remediate critical findings within 7 days.

13.3 Data Owners and Stewards

Review and approve classification levels for data in their domain at least annually.
Authorize access requests to Confidential and Restricted data through the access review process.
Conduct quarterly access reviews and revoke access that is no longer necessary.
Approve and maintain the retention schedule for data in their domain.
Participate in the Data Protection Impact Assessment (DPIA) process for new high-risk processing activities.

13.4 Security Team

Maintain and review this policy annually and upon material change to data processing activities.
Conduct or commission annual penetration testing and quarterly vulnerability assessments.
Manage the security incident response process including data breach notification obligations.
Review and approve all new third-party sub-processors; maintain the sub-processor register.
Monitor audit logs and security alerts in the SIEM; investigate anomalies per the Incident Response Plan.

13.5 Consequences of Policy Violation

Violation of this policy may result in disciplinary action up to and including termination of employment, and may expose the individual and QA Touch to civil or criminal liability. All violations are investigated and documented in accordance with the HR Disciplinary Policy.

14. Compliance Considerations

14.1 SOC 2 Trust Service Criteria Mapping

TSC ID	Criterion	How This Document Addresses It
CC6.1	Logical and physical access controls	Section 11 defines RBAC, MFA, session management, and least-privilege access for all data classifications.
CC6.2	New internal personnel access controls	Section 13 defines onboarding responsibilities; Section 4 defines data owner approval for access.
CC6.3	Third-party access controls	Section 9 enumerates sub-processors; DPA requirements defined; Section 8 defines controls applied to third-party data flows.
CC6.6	Logical access security measures	Section 11 defines authentication standards; Section 8 defines controls by classification.
CC6.7	Transmission controls	Section 10.2 defines TLS requirements for all data-in-transit flows.
CC7.2	Monitoring	Section 12 defines comprehensive audit log coverage, alerting, and SIEM requirements.
CC7.4	Incident response	Section 13 references Incident Response Plan; Section 12 defines triage SLAs.
C1.1	Confidential information identified	Section 2 catalogues all data elements; Section 3 defines the four-tier classification model.
C1.2	Confidential information protection	Sections 8, 10, and 11 define controls commensurate with classification level.
P1.1	Notice of data collection	Section 14.3 maps disclosure to Privacy Policy and applicable pages.
P4.1	Data quality	Section 6 defines seven data quality dimensions and associated controls.
P4.2	Data retention	Section 7 defines retention schedule with legal basis for each data type.
P6.1	Third-party disclosure	Section 9 provides the sub-processor register; Section 5.4 defines sharing rules.
A1.2	Availability monitoring	Section 12.3 defines monitoring and alerting; Section 6 defines Availability quality criteria.

14.2 Privacy Regulation Alignment

Regulation	Relevant QA Touch Obligations and Controls
GDPR (EU)	QA Touch acts as data processor for customer workspaces. DPAs with customers required. Data Subject Rights (access, erasure, portability, rectification) addressed in Privacy Policy and operationalized through Data Owner workflows. Data minimization principle applied to AI prompts and logs. DPIAs required for high-risk processing (AI features).
CCPA / CPRA (California)	QA Touch must honor Consumer Rights requests received from California-based customers or their end users. No sale of personal data. Updated Privacy Policy required. HR data of California employees covered separately.
PIPEDA (Canada)	Similar controller/processor obligations to GDPR. Privacy Policy must describe collection, use, and disclosure. Consent required for non-essential processing.
ISO 27001 (Framework)	Classification policy and controls align with ISO 27001:2022 Annex A controls (A.5.12 Classification of information, A.5.13 Labelling of information, A.8.24 Use of cryptography). QA Touch may seek ISO 27001 certification as a complementary assurance framework.
PCI DSS (Payment Data)	Billing payment data handled by PCI-compliant processor (Section 9); QA Touch should complete SAQ A or equivalent. Raw card data must never enter QA Touch systems.

14.3 Public Disclosure Mapping — Where Each Policy Element Belongs

IMPORTANT: This mapping is intended to guide QA Touch’s trust and transparency communications. Customer-facing pages should never expose operational security details (e.g., specific vendor names, internal IP ranges, or detailed implementation specifics) that could aid an attacker.

Policy Topic	Recommended Location(s)	What to Expose	What to Keep Internal
Data Categories Collected	Privacy Policy; Registration Page; User Settings	High-level list of data types collected: account info, workspace/project data, usage data, integration data, AI prompts (if applicable). Purpose of collection.	Internal database schema, specific field names, column structures.
Data Classification Framework	Internal SOC 2 Document Only; Trust Center (summary only)	Trust Center: ‘We classify data into sensitivity tiers and apply appropriate controls.’ No tier names or specific controls required publicly.	Full four-tier model, specific control mappings, classification criteria.
Data Owners	Internal SOC 2 Document Only	None. Ownership structure is an internal governance matter.	Full ownership and stewardship assignments.
Data Lifecycle (Collection, Processing)	Privacy Policy; Help Documentation	Privacy Policy: how data is collected, used, and processed. Help Docs: how imports, exports, and integrations work from a user perspective.	Internal system architecture, data flow diagrams, staging vs. production details.
Data Sharing with Third Parties	Privacy Policy; Trust Center; Security Page	Categories of sub-processors (cloud infrastructure, payment processor, email, analytics). Link to Sub-Processor List page. Statement that data is not sold.	Specific vendor names and contract terms (sub-processor list page may list vendor names as a separate public document).
Data Retention Guidelines	Privacy Policy; User Settings (data deletion info); Help Documentation	General retention periods for account data, workspace data, audit logs, and deletion upon account closure. User-facing deletion request process.	Full retention schedule with archive tiers, legal basis details, automated deletion job specifics.
Encryption at Rest	Security Page; Trust Center	’All customer data is encrypted at rest using AES-256.’ Key management via cloud KMS. Customer-managed keys available (if applicable).	Specific KMS provider, key rotation schedules, encryption architecture diagrams.
Encryption in Transit	Security Page; Trust Center; Privacy Policy	’All data in transit is encrypted using TLS 1.2 or higher.’ HTTPS enforced for all platform access.	Specific cipher suites, certificate authority, mTLS details.
Access Control / RBAC	Help Documentation; User Settings; Security Page	Help Docs: description of available user roles and permissions. Security Page: statement about least-privilege access and RBAC.	Internal IAM architecture, privileged access management specifics, break-glass procedures.
MFA / Authentication	Security Page; User Settings; Login Page; Help Documentation	Login Page: prompt/badge for MFA setup. User Settings: MFA enrollment flow. Security Page: MFA support statement. Help Docs: how to enable MFA.	Password hashing algorithm, token expiry values, internal auth architecture.
Audit Logging (Platform)	Security Page; Trust Center; Help Documentation	Security Page: ‘All user actions are logged with a tamper-evident audit trail.’ Help Docs: how to access the Activity Log in the workspace.	SIEM platform name, log retention backend, internal alerting rules.
AI Feature Data Handling	AI Feature Pages; Privacy Policy; Trust Center; Help Documentation	AI Pages: disclosure that user-provided prompts are sent to a third-party AI provider. Privacy Policy: AI data processing section. Trust Center: whether prompts are used for model training. Help Docs: what data is sent during AI generation and how to opt out.	Specific AI provider name (may be disclosed in Sub-Processor List), prompt retention period, model version.
Import/Export Data Handling	Help Documentation; Import/Export Screens; Privacy Policy	Import Screens: notice that uploaded files are processed and staging data is deleted post-import. Help Docs: supported formats, what is imported. Privacy Policy: reference to file upload processing.	Internal staging infrastructure, temporary storage bucket details.
Integration Data Handling	Integration Pages; Help Documentation; Privacy Policy	Integration Pages: what data is synced with each integration and what permissions are required. Privacy Policy: integration data processing. Help Docs: setup and data flow for each integration.	Internal integration architecture, OAuth token storage mechanism.
Third-Party Integrations List	Integration Page; About Page / Trust Center	Full list of supported integrations: Jira, Azure DevOps, GitHub, GitLab, Bitbucket, Slack, CI/CD platforms, automation frameworks.	Internal webhook implementation details, internal API credentials.
Security Controls (General)	Security Page; Trust Center	High-level controls: encryption, MFA, RBAC, penetration testing, vulnerability management, SOC 2 certification status, uptime SLA.	Specific control implementation details, pen test reports, vulnerability findings, SIEM configuration.
SOC 2 Certification / Report	Trust Center; Security Page	Statement of SOC 2 Type II compliance; link to request the report under NDA.	The full SOC 2 report and bridge letters (shared under NDA only).
Employee Responsibilities	Internal SOC 2 Document Only	None — internal governance document.	All content in Section 13.
Data Deletion / Subject Rights	Privacy Policy; User Settings; Help Documentation	How to request data deletion, portability, or correction. Link to data request form. Timeframe for response.	Internal data deletion workflow and tooling.
Tenant Isolation	Security Page; Trust Center	’Customer data is logically isolated between workspaces. No cross-customer data access is possible.‘	Database multi-tenancy architecture details.
Compliance and Certifications	Trust Center; Security Page; About Page	SOC 2 Type II, GDPR compliance statement, CCPA compliance statement, any ISO 27001 or other certifications.	Full compliance gap analysis, internal risk register.
Data Breach / Incident Notification	Privacy Policy; Terms of Service; Trust Center	Privacy Policy: notification obligations and timeline (e.g., 72-hour GDPR notification). Terms of Service: incident response obligations.	Internal incident response runbooks, specific alert thresholds.
Contact for Privacy/Security	Privacy Policy; Security Page; About Page	Email addresses: security@qatouch.com [VERIFY], privacy@qatouch.com [VERIFY]. Bug bounty or responsible disclosure policy link.	Internal escalation paths, on-call rotation.

15. Appendices

Appendix A: Glossary

Term	Definition
AES-256	Advanced Encryption Standard with a 256-bit key length. The current standard for symmetric encryption at rest.
Audit Log	A tamper-evident, chronological record of system events, user actions, and security-relevant occurrences.
Data Owner	A senior role accountable for a data category’s classification, access approval, and lifecycle management.
Data Processor	An entity that processes personal data on behalf of a data controller (QA Touch acts as processor for customer workspaces).
Data Steward	An operational role that manages day-to-day data quality and access on behalf of a Data Owner.
DPA	Data Processing Agreement. A contractual instrument required under GDPR and similar regulations when personal data is shared with a sub-processor.
DPIA	Data Protection Impact Assessment. A structured risk assessment required for high-risk processing activities under GDPR Art. 35.
GDPR	General Data Protection Regulation (EU 2016/679). The primary EU privacy regulation governing personal data processing.
KMS	Key Management Service. A cloud-provided system for generating, storing, rotating, and auditing encryption keys.
LLM	Large Language Model. The AI model type used by QA Touch’s AI test generation features.
mTLS	Mutual TLS. An extension of TLS where both the client and server authenticate each other using certificates.
RBAC	Role-Based Access Control. An access control model where permissions are assigned to roles, and users are assigned to roles.
SIEM	Security Information and Event Management. A platform that aggregates, correlates, and alerts on security log data.
SOC 2	Service Organization Control 2. An AICPA auditing standard evaluating controls relevant to Security, Availability, Processing Integrity, Confidentiality, and Privacy.
Sub-Processor	A third party engaged by QA Touch to process personal data on its behalf.
TLS	Transport Layer Security. A cryptographic protocol that provides secure communications over a network.
TSC	Trust Service Criteria. The control criteria evaluated in a SOC 2 audit, published by the AICPA.
Workspace	A logically isolated tenant environment within QA Touch representing a customer organization.

QAT-SEC-IRP-001 — Incident Response Plan
QAT-SEC-ACP-001 — Access Control Policy
QAT-SEC-ENC-001 — Encryption Policy
QAT-SEC-VM-001 — Vulnerability Management Policy
QAT-SEC-VRM-001 — Vendor and Third-Party Risk Management Policy
QAT-LEG-PP-001 — Privacy Policy (Customer-Facing)
QAT-LEG-TOS-001 — Terms of Service
QAT-HR-AUP-001 — Acceptable Use Policy
QAT-OPS-BCP-001 — Business Continuity and Disaster Recovery Plan
QAT-SEC-RET-001 — Data Retention Schedule

NextProduct Service Specifications