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: Trend summaries, anonymized charts.
• Internal / Operational data: System logs, performance metrics, non-personal metadata.
• Personal data: Account/profile info, contact details, support messages.
• Sensitive data / Special categories: If ever collected (e.g. payroll data for employees), 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. 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.

5. 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.

6. Technical and organisational measures (TOMs)

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

6.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.

6.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.

6.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.

6.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.

6.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.

6.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.

6.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.

6.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.

6.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.

6.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.

7. Third parties, subprocessors & vendor management

• We engage subprocessors (e.g., cloud providers, analytics, email, payment processors) under written contracts requiring adequate safeguards.
• Subprocessors are reviewed for security posture (SOC reports, ISO27001, penetration-test summaries, or equivalent).
• Threddle maintains a current subprocessors register and notifies customers of material changes as part of our DPA process.
• Customers may request the current subprocessor list and security attestations through our privacy contact.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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).

17. Contact & escalation

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