Legal
The formal compliance statement: who's the controller, who's the processor, where data goes, and exactly how to exercise your rights.
On this page
This page sets out, in more formal terms than our Privacy Policy, how Partyyy.Party meets its obligations under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018. It's aimed at hosts who want the detail behind our privacy practices — for example, before deciding whether to run their guest list through the Service.
This is the single most important thing to understand about how data protection law applies here:
Practically, this means a host is responsible for having a fair basis to collect their guests' data and for being transparent with their guests about it (our Privacy Policy is written so a host can point their own guests at it, but a host is welcome to write their own guest-facing notice too). We're responsible for processing that data securely, only as instructed, and only for the purpose of running the Service.
See the table in section 5 of our Privacy Policy for the lawful basis behind each specific use of data. In summary: host Account data is processed under contract; guest data is processed under the host's own basis (typically legitimate interest or contract with the guest), which we support as processor; AI renders and matchmaking rely on explicit consent; and security/anti-abuse processing relies on legitimate interest.
We use the following sub-processors to run the Service. Each is bound to process data only for the stated purpose and only on our (and, where relevant, the host's) instructions.
| Sub-processor | Purpose | Data involved |
|---|---|---|
| Resend | Transactional and invitation email delivery | Recipient email address, email content |
| Self-operated WhatsApp messaging integration | WhatsApp invitations and updates, where a host enables them | Guest mobile/WhatsApp number, message content, and — for avatar sync — profile photo |
| Google (Gemini API) | AI photo renders, scene generation, and group-photo detection | Uploaded photo, text prompt |
| xAI (Grok API) | AI photo renders | Uploaded photo, text prompt |
| Fly.io | Application hosting (London region) | All Service data, in transit and at rest on the platform |
| Neon | Managed database hosting | All Service data stored in the database |
| Cloudflare | Content delivery, security filtering, and object storage for photos | Traffic metadata (IP address); stored photo files |
Where a host actively chooses to search for a guest's photo on Instagram, Facebook, LinkedIn, or Gravatar from within their own dashboard, that lookup is triggered by the host, not run automatically by us — the host is exercising their own controller decision using our tooling, rather than us acting as their processor for that specific step.
We'll update this table if our sub-processors change, and a host is welcome to ask us for advance notice of material changes by emailing [email protected].
Our application hosting is in London. Where a sub-processor is based outside the UK — for example, Google, xAI, or Cloudflare may process data in the United States or other countries — we rely on the transfer safeguard the provider makes available, such as the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or the provider's certification under the EU–US Data Privacy Framework (which the UK extended to via the UK–US "data bridge"). We haven't independently audited each provider's specific safeguard documentation; if this is material to your decision to use the Service, email us and we'll share what we know, or you can check the provider's own transfer documentation directly.
| Data | Retention |
|---|---|
| Host Account data | While the Account is active, plus a limited period afterwards for legal, accounting, or fraud-prevention purposes |
| Guest data | While the host's Account and event remain active, or until the host or guest requests deletion, whichever is sooner |
| AI-rendered images | Same as other photos — deletable individually at any time |
| Security/scanner logs | Up to 30 days, then automatically pruned |
| Support correspondence | As long as reasonably needed to resolve and reference the matter raised |
We encrypt traffic to the Service in transit, store passwords as salted one-way hashes (never in plain text), restrict internal access by role, and run automated defences that detect and block known scanning and exploit patterns. Photo and file storage sits behind access-controlled cloud infrastructure rather than public storage. These measures are proportionate to a service of our current size and are reviewed as the Service grows — we don't claim certification against a formal standard (such as ISO 27001) at this stage.
If we become aware of a personal data breach affecting host or guest data, we'll assess it without undue delay, notify the Information Commissioner's Office within 72 hours where the law requires it, and notify affected hosts as soon as reasonably possible so they, in turn, can tell any of their guests who need to know — reflecting that hosts are the controller for their own guest data.
To make a data protection request (access, correction, deletion, restriction, objection, portability, or withdrawing consent), email [email protected] with as much detail as you can (which Account or event, and what you'd like us to do). We may need to verify your identity before acting on a request, particularly for deletion or access requests. We aim to respond within one calendar month, as required by UK GDPR, and will tell you if a request is complex enough to need longer.
If you're a guest, we may direct straightforward requests to your host first, since they're the controller and usually best placed to resolve it quickly (for example, correcting a dietary requirement) — but you're always entitled to come to us directly, and we'll act on a request ourselves where the host is unresponsive or where it concerns data we hold as controller (such as security logs).
Because we act as processor for a host's guest data, a host is entitled to a written data processing agreement covering that relationship. We don't currently publish a standard one, but a host can request one by emailing [email protected].
We haven't appointed a statutory Data Protection Officer, as UK GDPR doesn't currently require one at our scale (we don't carry out large-scale systematic monitoring or large-scale processing of special category data as a core activity). For all data protection matters, contact [email protected] directly.
We're currently reviewing whether registration with the ICO under the Data Protection (Charges and Information) Regulations 2018 applies to us, or whether an exemption does. We'll update this section once that's resolved, and you're welcome to ask us for our current position at any time.
Our lead supervisory authority is the UK's Information Commissioner's Office (ICO). You can lodge a complaint with the ICO at any time, whether or not you've raised it with us first — see section 16 of our Privacy Policy for their contact details.
We review this statement as the Service, our sub-processors, or our legal obligations change, and update the date at the top of this page whenever we do.
More of the small print