1. Purpose & scope

This page explains how Threddle protects personal data and store/business data that we collect, process, store, or otherwise access while delivering services. It applies to:

• All Threddle employees, contractors, interns, and temporary staff.
• All customers and partners who integrate stores, ad platforms, or other third-party systems with Threddle.
• All systems, applications, environments, and services that store, transmit, or process customer or user data.

This page covers both personal data (natural persons) and business/store data when that data contains personal data (e.g., customer emails in order data).

2. Key definitions (short)

• Personal data: Any information relating to an identified or identifiable natural person.
• Process / Processing: Any operation performed on personal data (collect, store, use, disclose, delete).
• Controller / Processor: Depending on context, Threddle may act as a controller (for our own users' account data) or a processor (when processing data on behalf of a business customer who is the controller).
• Subprocessor: Any third-party service provider engaged by Threddle to process personal data.

3. Data inventory & classification

We maintain a central register of data categories and systems (RoPA / Data Inventory). Data is classified into categories to guide handling and safeguards:

• Public / Aggregate data: Storefront catalog data, public product listings, aggregate sales metrics, trend summaries, and anonymized benchmark charts.
• Merchant Store Data: Store catalog, pricing structures, inventory levels, order metadata, and aggregate performance metrics processed to power Weave Research & Audit tabs, intelligence playbooks, and workflow executions. Note: Aggregate order metrics are processed strictly without end-customer PII; no consumer PII (such as customer names, email addresses, shipping addresses, or payment information) is transmitted to AI/LLM service providers.
• External Search & Crawling Queries: Search queries submitted to web-search providers and public storefront fetching data used to evaluate rule, tax, and ad-compliance requirements.
• Connected Advertising & Marketing Data: Advertising performance metrics (e.g., campaign, ad group, keyword, and product-level impressions, clicks, cost, conversions, conversion value, and ROAS) retrieved on the merchant's behalf from connected advertising accounts such as Google Ads and Meta Ads, under the merchant's OAuth authorization. Used solely to serve that merchant and displayed in their dashboard; no such data is sold, shared across customers, or used to train third-party models. Access to and use of Google Ads data adheres to the Google API Services User Data Policy, including its Limited Use requirements.
• Internal / Operational data: System logs, API telemetry, performance metrics, workflow audit logs, and non-personal system metadata.
• Personal data: Business account/profile info, merchant staff user credentials, contact details, and support communications.
• Sensitive data / Special categories: If ever collected (e.g. employee payroll details), handled with explicit justification and extra protections.

Each dataset entry in the inventory includes: data category, purpose, legal basis, storage location(s), retention period, owning team, subprocessors with access, and applicable protections.

4. Automated processing & store execution safeguards

Threddle provides Workflow Execution capabilities that enable automated and semi-automated changes to a merchant's connected e-commerce platform (e.g., Shopify) and connected third-party channels (such as Meta Ads, Google Ads, Klaviyo, and Mailchimp).

4.1 Scope of automated executions

Under configured workflow parameters, Threddle may execute changes to store resources including product pricing, collection structures, product descriptions and content tags, discount codes, inventory allocation rules, and marketing campaign settings.

4.2 Approval policies & merchant control

• Merchant Approval Settings: All automated workflow actions operate under approval and autonomy settings specified by the merchant. Merchants may require explicit manual approval for all store changes or configure automated execution policies with predefined bounds and thresholds.
• Pre-execution Verification: Before applying any automated change, Threddle performs verification checks to ensure data validity, API schema compliance, and adherence to configured price or discount guardrails.
• Audit Logging & Rollback: Every automated execution creates an immutable audit log capturing the change history, baseline state, and timestamp. Threddle provides single-click manual rollback and automated safety rollbacks if downstream errors or unexpected store conditions are detected.

5. Roles, responsibilities & governance

• Executives / Leadership: Approve security and data protection strategy and budgets.
• Data Protection Officer (DPO) / Privacy Lead: (If appointed) responsible for compliance oversight, regulatory liaison, and DSAR coordination.
• Security Team: Operational responsibility for infrastructure, application security, monitoring, and incident response.
• Product / Engineering: Implement secure-by-design principles, maintain SDLC security controls, and perform code reviews and testing.
• Legal / Compliance: Draft and maintain DPAs, review subprocessors, and advise on cross-border transfers.
• All employees: Responsible for following policies, attending mandatory training, and reporting incidents.

6. Processing principles & lawful basis

Threddle adheres to core data protection principles: lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, confidentiality, and accountability.

Where relevant, legal bases for processing include: contract performance, legitimate interest (balanced with risk), consent (where required), and compliance with legal obligations. For processing of customer/store data as a processor, contractual instructions and the Data Processing Agreement (DPA) govern processing.

7. Technical and organisational measures (TOMs)

Below are the primary controls Threddle uses to protect data. Controls are applied proportionally to data sensitivity and risk.

7.1 Governance & policies

• Documented security policy, access policy, encryption policy, secure development policy, incident response plan, backup & retention policy, and third-party risk policy.
• Periodic policy review at least annually.

7.2 Identity & access management

• Principle of least privilege and role-based access controls (RBAC).
• Multi-factor authentication (MFA) for all privileged accounts and recommended for user accounts.
• Centralized authentication (SSO) where applicable; ephemeral credentials for infrastructure access.
• Regular access reviews and attestation.

7.3 Encryption & key management

• TLS/HTTPS for data in transit.
• Encryption at rest for sensitive data fields and backups; keys stored in managed key-management systems.
• Key rotation policies and limited key access.

7.4 Network & infrastructure security

• Segmented networks (VPCs) and private subnets for internal services.
• Firewalls, WAFs, and network monitoring.
• Hardened OS images and minimal surface area for production services.
• DDoS protection and rate limiting for public endpoints.

7.5 Application security & secure SDLC

• Threat modeling for high-risk features.
• Static (SAST) and dependency scanning integrated into CI pipelines.
• Dynamic testing (DAST) for public-facing endpoints prior to release.
• Code reviews and security grooming as part of PR process.
• Vulnerability management with SLAs for patching.

7.6 Data minimization, pseudonymization & anonymization

• Minimize personal data collected; only fields necessary for the stated purpose.
• Pseudonymize or hash identifiers for analytics where feasible.
• Apply stronger anonymization where data is retained for trend modelling so that individuals are not re-identifiable.

7.7 Monitoring, logging & detection

• Centralized logging and retention aligned to regulatory and operational needs.
• Real-time alerting for suspicious activity (brute force, abnormal data access patterns, privilege abuse).
• Periodic log reviews and audit trails of admin and data-access operations.

7.8 Backups & disaster recovery

• Regular backups for production data with tested restore procedures.
• Backups encrypted and stored with separation from production credentials.
• Defined RTO/RPO targets; periodic DR drills.

7.9 Physical security

For any physical hosting or offices, access control, visitor logs, and locked server rooms; cloud providers' physical security controls are contractually ensured.

7.10 Employee security & training

• Mandatory security and privacy training during onboarding and recurring refreshers.
• Background checks for roles with elevated access where permitted.
• Clear disciplinary policy for misuse of data.

8. Third parties, subprocessors & vendor management

We engage vetted subprocessors under written data processing agreements requiring strict technical safeguards, confidentiality, and regulatory compliance. Subprocessors are audited periodically for SOC2/ISO27001 posture.

8.1 Subprocessor Register

Threddle maintains a current subprocessors register and notifies business customers of material subprocessor additions in accordance with our Data Processing Agreement (DPA).

9. International transfers & safeguards

• Personal data may be processed in or transferred to countries where we or our subprocessors operate.
• For transfers from regions with restricted transfer rules, we rely on appropriate safeguards such as standard contractual clauses (SCCs), adequacy, or explicit contractual mechanisms agreed in the DPA.

10. Data subject requests & DSAR handling (operational)

• Threddle provides mechanisms to exercise data subject rights (access, correction, deletion, portability, restriction, objection) through the account UI and privacy support channels.
• DSAR intake process: identity verification → search & scope scoping → data extraction → response or exception (within legal timeframe).
• Typical operational timelines: we aim to acknowledge DSARs within 5 business days and fulfill within statutory timelines (commonly 30 days) unless extended for complexity.

11. Incident response & breach notification

We maintain an incident response plan with roles, escalation paths, and communication templates.

• Detection & containment: Triage within hours of detection.
• Investigation: Root cause and scope (systems/data/records affected).
• Remediation: Fixing vulnerabilities and closing exploited vectors.
• Notification: Notify impacted customers and regulatory authorities as required by law. Notification content includes nature of the incident, data types affected, mitigation steps taken, and recommended customer actions.

Operationally, Threddle strives to provide initial notification to affected customers as soon as practicable and , where legally required , notifications to supervisory authorities in accordance with applicable law.

12. Records, audits & certification

• Threddle maintains records of processing activities and security documentation to demonstrate compliance.
• We cooperate with reasonable audits and will provide redacted reports (SOC2 Type II, ISO27001 certificates, penetration test summaries) when available under NDA or customer request.
• Internal and external penetration tests and vulnerability assessments are performed periodically.

13. Data retention & deletion (sample schedule)

Note: This is a sample; retention may vary per customer contract and legal obligations.

• Account and profile data: Retain while account is active + 2 years after termination (unless contractually required otherwise).
• Transactional / billing records: Retain for up to 7 years for tax and legal compliance.
• Logs and monitoring data: Retain for 90–365 days depending on type and regulatory needs.
• Backups: Retain according to backup policy and purge schedules; backups are immutable for a defined window and then recycled.
• Aggregated / anonymized trend data: May be retained indefinitely if fully de‑identified.

Requests for deletion are honoured subject to contractual and legal exceptions (e.g., tax records, legal hold).

14. Contact & escalation

For privacy or security enquiries, data requests, or to obtain security artefacts, contact Threddle's privacy team at: