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 connect a store or other third-party system to 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. The personal data we hold relates to the merchant staff who use Threddle — account and profile details, contact information, and support correspondence.

We do not receive end-customer personal data from connected stores. Threddle is not approved for Shopify's protected customer data, and our sync does not request it. Shopper names, email addresses, phone numbers, shipping and billing addresses, and payment details are never requested, received, or stored — the corresponding fields are left empty by design. This position is stated consistently in sections 3 and 8.1 below.

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 and intelligence playbooks. Note: Aggregate order metrics are processed strictly without end-customer PII. Threddle is not approved for Shopify's protected customer data and does not request it, so no consumer PII (such as customer names, email addresses, shipping addresses, or payment information) enters the platform at all — and none is transmitted to AI/LLM service providers.
• External Search & Crawling Queries: Search queries submitted to web-search providers and publicly accessible storefront pages fetched to support competitor and demand research. These queries are derived from catalog and category terms; they do not contain end-customer personal data.
• 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.

3.1 Planned data categories (not collected today)

The categories below are on our roadmap. They are listed here for transparency about our direction only. Threddle does not collect, receive, or process any of this data today, and no such integration exists in the product. If and when one ships, this page and the subprocessor register in section 8.1 will be updated before any data is collected, and affected customers will be notified under the DPA.

• Connected advertising & marketing data (planned): Advertising performance metrics retrieved on a merchant's behalf from advertising accounts they connect. No advertising platform integration is built, and Threddle holds no advertising account credentials or tokens.
• Connected marketing channels (planned): Email and messaging campaign metrics from platforms a merchant chooses to connect.

4. Automated processing & store executions

4.1 Current position: read-only access

Threddle's access to a connected store is read-only today. The platform reads catalog, pricing, inventory, location, and order-level data to generate recommendations. It does not write to, modify, or delete anything in a merchant's store.

Playbook recommendations are presented in the dashboard for the merchant to review and act on themselves. Approving or dismissing a card records that decision inside Threddle; it does not push a change to the store.

4.2 Automated store executions (planned)

Automated and semi-automated execution of store changes is planned functionality. It is not available today, and no execution path to any connected store or third-party channel is live. We are documenting the intended safeguards here so that customers can evaluate them in advance. We are not committing to a delivery date, and none of the controls below should be relied on as operating today.

• Merchant approval settings: Execution will operate under approval and autonomy settings specified by the merchant, including the option to require explicit manual approval for every store change.
• Pre-execution verification: Validation of data, API schema compliance, and configured price or discount guardrails before any change is applied.
• Audit logging and rollback: An append-only record of each execution capturing the change, baseline state, and timestamp, together with a merchant-initiated rollback path.

When this functionality ships, this section will be rewritten to describe the controls actually in operation, and customers will be notified in accordance with the DPA.

5. Roles, responsibilities & governance

Threddle is an early-stage company with a small engineering team. We have not established separate security, legal, or compliance functions, and we do not claim to. Responsibility is allocated as follows.

• Privacy & Security Lead: A named member of the founding team holds accountability for data protection, subprocessor review, incident response, and handling data subject requests. This is the responsible contact for anything on this page and is reachable at contact@threddle.com. We have not appointed a statutory Data Protection Officer; we have assessed that we are not currently required to and will appoint one if that changes.
• Engineering: Implements and operates the technical controls described in section 7, reviews changes before they are merged, and maintains the production environment.
• External counsel: Engaged as needed for DPAs, cross-border transfer mechanisms, and regulatory questions. We do not maintain an in-house legal or compliance function.
• Everyone at Threddle: Responsible for following our internal policies and reporting suspected incidents immediately.

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)

Sections 7.1 to 7.7 describe controls that are operating today. Section 7.8 lists controls that we do not yet run — several of which appear on standard vendor security questionnaires — so that customers can assess us on what is actually in place rather than on what a policy page aspires to. We would rather be checkable than impressive.

7.1 Identity & access management

• Principle of least privilege. Production access is limited to the engineers who require it for their work.
• Multi-factor authentication is enabled on the cloud provider, database, and source control accounts that hold production access.
• Tenant isolation is enforced in the application layer, with every data query scoped to a single tenant, and by row-level security policies on the primary database.
• Service credentials and API keys are held in Google Secret Manager and injected at deploy time. They are not stored in source control.

7.2 Encryption & key management

• TLS/HTTPS for data in transit.
• Encryption at rest is provided by the managed services we run on — Google BigQuery, Google Cloud Storage, and the Supabase Postgres database — under their own default encryption.
• Shopify OAuth tokens are additionally encrypted at the field level before they are written to the database, with the encryption key held in Secret Manager and never stored alongside the data.

7.3 Network & infrastructure security

• Production services run inside a single dedicated Google Cloud project with project-scoped IAM.
• Rate limiting on public API endpoints, and per-minute limits on outbound calls to every external provider.
• Managed, provider-maintained base images for compute; DDoS protection and edge filtering are provided by the cloud platform.

7.4 Application security

• Changes are reviewed before they are merged.
• Automated test suites cover the API and worker services and are run against changes.
• Dependencies are pinned per service and updated when we become aware of a relevant vulnerability.

7.5 Data minimisation

• We do not request Shopify's protected customer data. Shopper identity fields are never populated.
• Order data is processed as identifiers and aggregate values; no shopper-level records are built.
• Search and crawl queries are derived from catalog and category terms, never from personal data.

7.6 Monitoring & logging

• Application and infrastructure logs are centralised in Google Cloud Logging.
• LLM prompt and completion telemetry is captured in Langfuse for debugging and quality review. See the subprocessor register in section 8.1.
• Errors and failed jobs are surfaced to the engineering team for triage.

7.7 Backups & physical security

• The primary database is backed up automatically by our managed database provider under its standard backup schedule. Analytical data in BigQuery and Cloud Storage relies on Google Cloud's durability and versioning.
• Threddle operates no data centres, server rooms, or physical hosting of its own. Physical security of the infrastructure is the responsibility of Google Cloud and our managed database provider under their own certifications.

7.8 Planned controls (not in operation today)

The following are on our roadmap. We are deliberately not attaching target dates to them, and none of them should be treated as a commitment we are currently meeting. This page will be updated as each one starts operating.

• Static analysis (SAST) and automated dependency scanning in a continuous integration pipeline. We do not currently run a CI pipeline.
• Dynamic application security testing (DAST) of public-facing endpoints ahead of releases.
• Formal threat modelling for high-risk features.
• Independent penetration testing. No external penetration test has been performed to date.
• A documented disaster recovery plan with defined RTO and RPO targets, and rehearsed restore drills. Backups exist, but we have not yet formally defined or tested recovery objectives.
• Scheduled access reviews with recorded attestation.
• Background checks for roles with elevated access.
• A recurring mandatory security and privacy training programme.
• A formally documented policy set and a vulnerability management policy with published remediation SLAs.
• SOC 2 Type II and ISO 27001 certification. Threddle holds neither today.

8. Third parties, subprocessors & vendor management

We engage subprocessors under their standard data processing terms, which require technical safeguards, confidentiality, and regulatory compliance. Before onboarding a subprocessor we review its published security documentation, certifications, and data processing terms. We do not conduct our own audits of our subprocessors and rely on the third-party certifications each vendor publishes.

8.1 Subprocessor Register

The register below lists every subprocessor that handles data for the Threddle platform today. Each entry corresponds to a service that is actively integrated and in use. No entry describes a planned or prospective integration.

No subprocessor in this register receives end-customer personal data. Because Threddle is not approved for Shopify's protected customer data and does not request it, shopper names, email addresses, phone numbers, addresses, and payment details do not exist in our systems and therefore cannot be passed onward. Order data shared with any provider below is limited to identifiers and aggregate values.

Platform subprocessors

Marketing website subprocessors

These services support threddle.com, our public marketing website, only. They have no access to the Threddle platform, to any connected store, or to merchant data. They are listed separately because they operate in a different scope from the platform subprocessors above.

Merchant-supplied AI keys

Settings include an optional field for a merchant to supply their own AI provider API key. If you choose to use it, requests for your tenant are sent to the provider you nominated, under your own account and terms with that provider, and that provider becomes a subprocessor for your tenant alone. This is off by default. If you do not configure a key, only the providers listed above are used.

Threddle maintains this register as the current and authoritative list, and notifies business customers of material subprocessor additions in accordance with our Data Processing Agreement (DPA). If you believe a service is missing from it, tell us and we will correct it.

9. International transfers & safeguards

9.1 Where your data is stored

Threddle stores and processes customer data in the United States, regardless of where the merchant is located. Specifically:

• Analytical data — store catalog, pricing, inventory, aggregate order metrics, and market signals — is held in Google Cloud, region us-central1 (BigQuery, Cloud Storage, and Compute Engine), in a single dedicated Google Cloud project.
• Authentication records, account data, tenant configuration, and encrypted store access tokens are held in our managed Postgres database with Supabase, region us-west-1.
• The subprocessors listed in section 8.1 process data in the regions named there. Proxy infrastructure is the exception: it routes outbound requests for public market pages through the country being observed, and carries no customer data.

We do not currently offer regional data residency in the EU, the UK, or India. If your organisation requires it, contact us before signing so we can tell you honestly whether we can meet your requirement.

9.2 Transfer mechanisms

• EEA, UK and Swiss merchants: Because processing takes place in the United States, we rely on the European Commission's Standard Contractual Clauses (SCCs), with the UK International Data Transfer Addendum where the UK GDPR applies, incorporated into our Data Processing Agreement. Our subprocessors are engaged on SCCs or an equivalent approved mechanism under their own terms.
• Indian merchants: Transfers are made in reliance on the cross-border transfer provisions of the Digital Personal Data Protection Act, 2023 (DPDP Act), which permit transfer to countries not restricted by the Central Government. We will adjust our arrangements if the notified restrictions change.
• Other regions: Where local law requires a specific safeguard, the mechanism is agreed in the DPA before processing begins.

A copy of our DPA, including the transfer annexes, is available on request.

10. Data subject requests & DSAR handling (operational)

• How to make a request: Data subject rights (access, correction, deletion, portability, restriction, objection) are exercised by writing to contact@threddle.com. We handle these requests manually. There is no self-service data export or account deletion control in the dashboard today; building one is on our roadmap, and until it exists the email route is the only mechanism and we will not imply otherwise.
• 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 the data inventory described in section 3.
• Threddle does not hold SOC 2 Type II or ISO 27001 certification, and has not commissioned an external penetration test. We would rather tell you this directly than let a security questionnaire discover it. Both are listed as planned controls in section 7.8.
• We respond to customer security questionnaires and due diligence requests directly, and will answer them accurately including where the answer is "not yet". Where a reasonable audit right is agreed in a DPA, we will honour it.

13. Data retention & deletion

This is our retention schedule. Where a customer contract or a legal obligation sets a different period, that period governs for the customer concerned.

Deletion on account closure is carried out manually today. Requests for deletion are honoured subject to contractual and legal exceptions (for example tax records or a legal hold), and we will tell you which exception applies if we cannot delete something you have asked us to delete.

14. Contact & escalation

For privacy or security enquiries, data subject requests, security questionnaires, or a copy of our DPA, write to us. This address reaches the person accountable for data protection at Threddle, described in section 5.