This page describes how DomiDo handles the personal data that flows through the platform. Personal data enters the system through Open Authorisation registration, through the payment flows the platform routes to Stripe, through the design-creation pipeline that processes prompts and reference images, and through the analytics that observe how the product is used. Processing is governed by the United Kingdom General Data Protection Regulation (the retained European Union General Data Protection Regulation as applied in the United Kingdom), by the Data Protection Act 2018, by the Privacy and Electronic Communications Regulations 2003 as amended by the Data Use and Access Act 2025, and by the published guidance of the Information Commissioner's Office. The sections that follow describe how the platform classifies that data, what lawful basis stands behind each processing activity, what data-subject rights the platform implements and how, where the data travels and on what legal mechanism, how long it is kept, and how breach notification, cookie consent, and the supporting impact assessments are run. The posture is conservative on every dimension that touches cardholder data — Stripe handles every cardholder-data flow, the platform never sees a Primary Account Number — and proportionate elsewhere, with retention windows tied to tax and consumer-law limitation periods rather than to operational convenience.
Personal data is classified into sensitivity tiers that drive the controls applied to it, and the most important entries in the table below are the exclusions: the platform's systems never handle the full Primary Account Number, the Card Verification Value, magnetic-stripe data, the Personal Identification Number, or any other raw cardholder data, because all card-data entry happens on Stripe-hosted Checkout pages rather than on the platform's own surfaces.
| Tier | Definition | Examples | Controls |
|---|---|---|---|
| High | Raw payment-card data | Full Primary Account Number, Card Verification Value, Personal Identification Number | Never collected, stored, or transmitted by the platform — Stripe handles every cardholder data flow |
| Standard personal data | Data identifying a natural person | Name, email, delivery address, IP address | Encrypted at rest with Advanced Encryption Standard 256, encrypted in transit with Transport Layer Security 1.2 or higher, access-controlled, retention-limited |
| Identifier | Tokens referencing external data | Stripe Customer ID, SetupIntent ID, PaymentIntent ID | Stored with access control; no direct personal-data disclosure |
| Tokenised | Partial or masked values | Last four digits of a card, card brand, expiry | Display-only; cannot reconstruct the full number |
| Pseudonymised | Data with direct identifiers removed | Analytics events with a user hash | PostHog European Union region; no analytics cookies before consent |
| Low | Non-personal operational data | Design metadata, three-dimensional model files, pipeline outputs | Standard access control; no specific personal-data obligations unless linked to an identified person |
Beyond the tiers themselves, several operational rules constrain where personal data is allowed to appear. Personal data never appears in application logs (with the single exception of IP addresses in access logs, which are kept on a ninety-day retention), in error-tracking payloads, in analytics events, in object-storage file names, or in queue and cache entries. The exclusion is enforced by the way each surface is constructed rather than by an after-the-fact scrubbing pass: the logging library refuses to serialise identified fields, error tracking strips known personal-data keys from payloads, the analytics integration pseudonymises user identifiers before events are emitted, object-storage keys use opaque identifiers rather than human-readable filenames, and queue and cache entries reference resources by identifier rather than by personal-data content.
Different processing activities rely on different lawful bases under Article 6, and the table below records the basis claimed for each principal activity together with the Article subsection that supports it. The bases shift depending on whether the activity is necessary for contract performance, anchored in a legal obligation, supported by a legitimate-interest assessment, or dependent on the user's consent.
| Processing activity | Lawful basis | Article |
|---|---|---|
| Processing orders (name, address, payment details) | Contract performance | 6(1)(b) |
| Customer account management | Contract performance | 6(1)(b) |
| Transactional emails (order confirmation, delivery updates) | Contract performance | 6(1)(b) |
| Marketing emails | Consent for new contacts; soft opt-in for existing customers under the Privacy and Electronic Communications Regulations regulation 22 | 6(1)(a) |
| Website analytics | Consent, with analytics cookies consent-gated | 6(1)(a) |
| Fraud prevention (IP logging, rate limiting) | Legitimate interest | 6(1)(f) |
| AI model training on user designs | Consent (explicit opt-in, not engaged at early launch) | 6(1)(a) |
| Designer royalty payments at the manufacturing phase | Contract performance | 6(1)(b) |
| Tax record retention | Legal obligation | 6(1)(c) |
| AI-generated content processing | Consent (where the user uploads reference photos containing personal data) or legitimate interest (where input is text-only with no personal data) | 6(1)(a) or 6(1)(f) |
Two of the entries deserve a note in prose. AI model training on user designs is not engaged at early launch and only ever proceeds under explicit opt-in consent rather than as a default; the consent record described later in this page is what makes that distinction auditable. AI-generated content processing splits between consent and legitimate interest depending on whether the user uploads reference photos containing personal data or supplies text-only prompts; because reference photos may contain faces, property, or other identifiable content, the platform's not-safe-for-work pre-screen runs against uploaded images before generation, and the lawful-basis choice follows the actual data category of each input rather than the marketing description of the feature.
The published privacy policy is concise, transparent, intelligible, and easily accessible under Article 12. It records the identity and contact details of Avvyland Limited; the purposes and lawful basis for each processing activity; the categories of recipients (Stripe, the storage provider, the analytics provider, the AI providers, and the email provider); the international transfers performed and the safeguards that authorise them; the retention period per data category; the data-subject rights (access, rectification, erasure, restriction, portability, objection); the right to withdraw consent; the right to complain to the Information Commissioner's Office; and the automated-decision-making disclosure that Article 22 expects when relevant processing is taking place. The privacy policy is one of the eight legal pages that the platform publishes at launch, and it sits alongside the cookie banner and the in-account privacy controls as the user-facing surface of the rights and bases recorded on this page.
Every right in Articles 15 to 22 is implemented through a defined platform surface. The right of access under Article 15 is served through an account-settings page for personal-data viewing and through an email-based process for comprehensive Subject Access Requests; both run to the one-month statutory response deadline. The right to rectification under Article 16 is served through self-service updates of the name, the email, and the address, with email changes requiring re-verification so that a hijacked session cannot quietly redirect notifications to a different inbox. The right to erasure under Article 17 is served through account deletion, which anonymises the name to "Deleted User", hashes the email, removes the address, disassociates designs, and cancels any active Stripe subscriptions; the anonymised record is retained for seven years for tax purposes so that the underlying financial trail remains intact while no personal data remains attached to it. The right to data portability under Article 20 is served through a JavaScript Object Notation export covering the account profile, every design (including the three-dimensional model files), the order history, and the consent records, so the user takes away both the content they created and the consent context that surrounded it. The right to object under Article 21 is served through the cookie-consent withdrawal mechanism and through a general objection form for the cases that the cookie banner does not cover. Account deletion uses a fourteen-day cooling-off period before execution so that an accidental click can be reversed rather than turned into a permanent loss.
Consent records sit in an immutable collection that the application appends to rather than mutates in place. Each record contains the user identifier, the consent type (marketing, analytics, AI training), the consent text that was shown at the time of the action, a timestamp, the IP address, and the granted-or-withdrawn status. Withdrawal is recorded as a new entry with withdrawn: true rather than by deleting or overwriting the original grant, so the full audit trail is preserved against any later challenge to the consent the platform claims to hold. Marketing-consent withdrawal takes effect within twenty-four hours of the withdrawal record being written, which is the practical horizon for the email provider to absorb the suppression instruction and stop the next scheduled send.
Personal data flows through a small set of third-party services, and each transfer rests on a documented legal mechanism. Most of the routing stays inside the United Kingdom and the European Economic Area adequacy zone; the transfers that leave that zone are restricted to the categories of data that the receiving service genuinely needs to perform its function.
| Service | Data transferred | Destination | Transfer mechanism |
|---|---|---|---|
| MongoDB Atlas | All application data | European Union (Frankfurt) | No transfer outside the United Kingdom and European Economic Area adequacy zone |
| Stripe | Payment personal data (name, email, address) | United States and European Union | United Kingdom Extension to the European Union-United States Data Privacy Framework (Stripe is certified) |
| Object storage | Three-dimensional models and images | European Union (Falkenstein) | No transfer outside the adequacy zone |
| PostHog | Analytics events | European Union | No transfer outside the adequacy zone |
| AI image providers (Gemini, Recraft, FLUX) | Text prompts and reference images | United States and European Union (varies) | United Kingdom Extension to the European Union-United States Data Privacy Framework (Google); per-provider Transfer Risk Assessment |
| AI 3D providers (Hunyuan, Meshy, Tripo) | Multi-view images and 3D geometry | China (Tencent), United States, European Union | Per-provider Transfer Risk Assessment; design data is parametric, not personal data |
| Email provider (Postmark) | Email address and name | Provider hosting location | United Kingdom adequacy decision or International Data Transfer Agreement as required |
A Transfer Risk Assessment runs before integrating any new third party that processes personal data, so the legal mechanism is selected against the actual data category and destination rather than treated as a one-time setup task that never revisits the position.
Retention is set per data category rather than as a single horizon, because the categories serve different purposes and the controlling legislation differs between them. The schedule below records the retention period and the deletion mechanism for each category that the platform stores.
| Data category | Retention | Deletion |
|---|---|---|
| Active user account data | Duration of the account | Anonymisation on deletion |
| Deleted user account data | Seven years from deletion | Hard delete after retention |
| Order and transaction records | Seven years from transaction | Hard delete after retention |
| Access logs with IP | Ninety days | Automatic retention policy |
| Analytics data | Twenty-six months rolling | Automatic retention policy |
| Audit logs | Seven years | Hard delete after retention |
| Refresh tokens (expired or consumed) | Twenty-four hours | Time-to-live index |
| Cookie consent preferences | Thirteen months | Cookie expiry |
| Product recall records | Eleven years from last sale | Hard delete after retention |
The seven-year retention applied to financial records aligns with His Majesty's Revenue and Customs requirements under the Companies Act 2006 and the Value Added Tax regulations, which is why the deleted-user record, the order record, and the audit log share the same horizon even though the data they contain is different. The eleven-year retention on product recall records is set against the Consumer Protection Act 1987 limitation period for the product-safety regime described on the Product safety page, rather than against the financial regime.
In the event of a personal-data breach, the Information Commissioner's Office is notified within seventy-two hours of awareness if the breach is likely to result in a risk to individuals' rights and freedoms. Data subjects are notified without undue delay if the breach is likely to result in a high risk, and the notification carries the practical information the data subjects need to protect themselves rather than a generic apology. Every breach is documented in a breach register whether it crosses the notification threshold or not, so the regulator can be answered against the register if the threshold itself is later contested. Tabletop exercises run quarterly to test the notification process so that the seventy-two-hour clock does not catch the team learning the process for the first time. Failure to notify within seventy-two hours can result in separate fines independent of the breach itself, and the upper limits sit at four per cent of annual global turnover or seventeen-and-a-half million pounds — the higher of the two — which is the reason the quarterly drill exists in the first place.
Three cookie categories operate. Strictly necessary cookies are always active and are exempt from the Privacy and Electronic Communications Regulations: they cover the session, the Cross-Site Request Forgery token, the consent record itself, and the cart. Analytics cookies, served by PostHog, are disabled until consent is granted, and the PostHog software development kit initialisation is gated behind the consent check rather than loaded eagerly and disabled at runtime. Marketing cookies are not used at early launch and are disabled until consent if they are introduced later. The cookie banner appears on every page until the user makes a choice, and the surface follows the Information Commissioner's Office expectations on dark patterns: the "Reject all" control is equally prominent as "Accept all", there are no cookie walls, and granular customisation is available so that the user can accept some categories without being forced into a binary choice. The consent cookie expires after thirteen months in line with the retention schedule above, and a persistent "Cookie settings" footer link allows withdrawal at any time.
A Data Protection Impact Assessment runs before deploying any Artificial Intelligence system that processes personal data, before introducing profiling or automated decision-making, before any large-scale processing activity, and before any new high-risk activity that Article 35 brings within scope. The initial Assessment covering the core platform is completed before public launch, so the platform does not open with high-risk processing whose impact has not yet been assessed.
Because Stripe Checkout and Stripe Elements handle every cardholder-data flow, the platform qualifies as a Self-Assessment Questionnaire A merchant — the simplest of the available levels. The Questionnaire is completed annually and an Attestation of Compliance is submitted alongside it; the annual cadence is part of the compliance calendar rather than left to recall.
Consumer-protection law sits next to data-protection law because the same surfaces — the order flow, the account, the support conversation — are governed by both. The Consumer Rights Act 2015 governs digital content and goods, and the platform meets the obligations on satisfactory quality, fitness for purpose, description match, and refund mechanics. The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 require pre-contract information and a fourteen-day cooling-off period for distance sales of physical goods that have not been opened, with the right to cancel running from delivery rather than from order. The Sale of Goods Act 1979 thirty-day right-to-reject window provides an additional consumer remedy on top of those, and the platform's refund processes operate within the statutory timeframes rather than against a private service-level target.
The Privacy and Electronic Communications Regulations 2003 govern marketing emails and similar electronic communications. New contacts require opt-in consent recorded against the consent collection described above, and existing customers fall under the soft opt-in for products and services similar to those previously purchased, subject to a clear unsubscribe path on every communication that the soft opt-in covers. Marketing channels respect every unsubscribe within twenty-four hours of receipt, which matches the marketing-consent-withdrawal horizon set above so that the user-facing experience is consistent regardless of whether the request comes through the unsubscribe link or through the consent withdrawal flow.
The audit log records every privacy-relevant event: consent grants and withdrawals, data-subject request submissions and the responses returned to them, account deletions together with the cooling-off period state, breach detections and the notifications that followed them, and Transfer Risk Assessment updates. The log retains every event for seven years in line with the retention schedule above. Avvyland Limited is not required to appoint a Data Protection Officer under the United Kingdom General Data Protection Regulation Article 37 thresholds — the platform's processing does not meet the criteria that trigger the appointment — but a privacy lead within the leadership team carries the equivalent responsibility and is the contact point for the Information Commissioner's Office and for data subjects who reach out about their data.