Sortr — Privacy Policy
Last updated: 9 July 2026
This policy explains what personal data Micromat Limited, a company registered in England and Wales (company number 13455386) whose registered office is at 6 Carnegie Street, Rushden, NN10 9SN, trading as 'Sortr' ("Sortr", "we", "us") collects, why we collect it, how we use it, who we share it with, and what rights you have under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.
If you have any question about this policy, contact us at hello@sortr.uk or write to us at our registered office at 6 Carnegie Street, Rushden, NN10 9SN.
1. Who we are (data controller)
Micromat Limited (company number 13455386, registered office 6 Carnegie Street, Rushden, NN10 9SN) is the data controller for the personal data described in this policy. We are registered with the UK Information Commissioner's Office (ZC189975); Micromat Limited will complete ICO registration before public launch.
The two-contract structure described in our customer terms (you contract with Micromat Limited for the platform service AND with the individual Sorter for the task) does not change who is responsible for the data the app collects: Micromat Limited is the controller for all data the app collects through your account, your bookings, and your in-app activity. Sorters see your personal data only through the in-app surfaces Sortr designs, and may use it only to perform the booked task. If a Sorter processes your personal data outside the platform (which our Sorter terms prohibit except as needed to perform the task), the Sorter is a separate data controller for that processing and is responsible for it in their own right.
Some organisations we work with are independent controllers of certain data rather than our processors — most notably Stripe for identity verification (see §2.3 and §3).
2. What personal data we collect
2.1 When you create an account
| Data | Purpose | Lawful basis |
|---|---|---|
| Email address | Login + transactional email | Contract performance (Art. 6(1)(b)) |
| First + last name | Identify you on bookings + reviews | Contract performance |
| Password (hashed, never stored in plaintext) | Authentication | Contract performance |
| Date of birth (Sorter accounts only) | Age assurance (Sortr is 18+ — see §7); verified through Stripe identity verification | Contract performance + legitimate interests (age assurance) |
| Phone number (optional for customer; required for Sorter for SOS) | SMS-distributed share links, Sorter emergency contact | Contract performance + legitimate interests (Art. 6(1)(f)) |
2.1A When you sign in with Apple or Google
If you choose to create or access your account using Sign in with Apple or Sign in with Google instead of an email and password, the provider returns a signed identity token (an "id-token") from which we collect and store:
| Data | Purpose | Lawful basis |
|---|---|---|
Provider subject identifier (provider_subject — a stable, provider-issued ID that is opaque to us) |
Link the sign-in to your Sortr account so you can log back in | Contract performance (Art. 6(1)(b)) |
Provider email address (provider_email) |
Login + transactional email (as in §2.1) | Contract performance (Art. 6(1)(b)) |
| Name returned by the provider | Your counterparty-facing marketplace name — the name customers and Sorters see on bookings and reviews, exactly as in §2.1 | Contract performance (Art. 6(1)(b)) |
Your name is collected because Sortr is a two-sided marketplace where the other party to a booking must see who they are dealing with; it is not an optional or "email-only" sign-in. If you sign in without releasing a name, we will ask you to supply one.
Apple "Hide My Email" relay addresses. If you use Apple's Hide My Email feature, the provider_email we receive is an Apple-operated relay address (@privaterelay.appleid.com) rather than your personal address. We store and flag the address as an Apple relay so that our email to you is routed through Apple's relay and so we handle it correctly on erasure. Mail we send to a relay address is forwarded to you by Apple; if you later disable forwarding, that mail will stop reaching you.
Apple refresh token. To be able to honour Apple's account-deletion and consent-revocation signals (below), we exchange the one-time authorizationCode Apple returns at sign-in for an Apple refresh token, which we hold encrypted at rest with AES-256-GCM. We use it only to call Apple's token and revocation endpoints; it is never shared and is destroyed when your linked identity is removed.
Apple server-to-server notifications. Apple sends us server-to-server (S2S) notifications when you delete your Apple ID or revoke Sortr's access from your Apple account settings. On receiving an account-delete or consent-revoked notification we begin a deferred erasure of your linked identity: erasure is held only until any booking that is still in progress reaches a terminal state, and then completes within approximately 15 minutes of that point (UK GDPR Art. 17(1)(a) read with the Art. 17(1) "without undue delay" standard — while a booking is still in progress the linked identity is still needed to finish that service, so we complete erasure without undue delay once it ends; Art. 17(3)(e)/(3)(b) may additionally apply only where a specific record must be kept for legal claims or to meet a legal obligation). We make the equivalent revocation call to Apple if you delete your Sortr account from our side.
2.2 When you book a task (customer)
| Data | Purpose | Lawful basis |
|---|---|---|
| Booking address (full text + postcode) | Sorter routing + service-area gating | Contract performance |
| Geographic coordinates (lat/lng) of the address + task pins | Map rendering + sorter-distance calculation | Contract performance |
| Optional task notes | Communicate task specifics to the Sorter | Contract performance |
| Payment method token (Stripe-issued; we never see your card number) | Payment authorisation + capture | Contract performance |
| Booking history (statuses, times, total prices) | Provide booking detail + receipt + review surfaces | Contract performance (Art. 6(1)(b)) + legal obligation (Art. 6(1)(c) — UK tax and accounting record-keeping, see §5) |
| Tip amount + payout breakdown | Settlement with the Sorter | Contract performance |
2.3 When you become a Sorter
| Data | Purpose | Lawful basis |
|---|---|---|
| Identity-verification status + non-document account fields received back from Stripe (pending / verified / requires action) | Payout account setup + fraud prevention | Contract performance (Art. 6(1)(b)) + legitimate interests (fraud prevention) |
| Profile photo | Customer reassurance + safety | Legitimate interests (safety + trust) |
| Approximate location while on an active booking (foreground-only) | Live arrival tracking for the customer; ETA badges | Contract performance |
| Emergency contact name + phone (SOS) | Sorter safety — contacted only if you trigger SOS | Legitimate interests (Sorter safety); vital interests (Art. 6(1)(d)) in an emergency |
| National Insurance Number (collected before your first payout) | HMRC digital-platform reporting (see §2.11) | Legal obligation (SI 2023/817) |
Identity verification is performed by Stripe Payments Europe Ltd as an independent data controller under its own anti-money-laundering and regulatory obligations. Stripe's processing of your ID document, selfie (including biometric facial comparison) and date of birth is described in Stripe's Privacy Policy (https://stripe.com/gb/privacy). Sortr never receives or stores a copy of your ID document or selfie; we receive only your verification status and non-document field values.
2.4 When you complete a task
| Data | Purpose | Lawful basis |
|---|---|---|
| Proof-of-work photos (before / after / issue, max 6 per booking) | Customer reassurance + dispute evidence | Contract performance |
| In-app GPS coordinates + capture time embedded in each photo | Anti-fraud (location attestation) | Legitimate interests (fraud prevention) |
| Device-integrity attestation token (Apple DeviceCheck or Google Play Integrity) | Anti-spoof gate at upload | Legitimate interests (fraud prevention) |
Proof photos are stored on our own infrastructure (MinIO object storage); they are not uploaded to any third-party photo service. After the booking (plus a 24-hour grace window for re-capture), photos are kept for the establishment and defence of legal claims (legitimate interests, Art. 6(1)(f) — you have the right to object, see §6):
- No dispute raised: proof photos are deleted 180 days after the booking reaches its final state (this covers the outer card-chargeback window).
- Dispute raised: photos attached to the dispute are kept for 180 days after the dispute closes, then moved to cold storage for 90 days (audit access only), then permanently deleted. This matches the schedule in our customer terms §8.
If a dispute is raised, proof photos may be shown to the other party to the booking and to Sortr Resolution staff. Please avoid photographing people — frame the task area only. Photos sometimes capture other members of a household incidentally; where they do, those people's images are processed only as part of the dispute evidence described here.
2.5 When you raise a dispute
| Data | Purpose | Lawful basis |
|---|---|---|
| Free-text complaint (75-5000 characters) | Sortr Resolution admin review | Contract performance |
| Optional voice complaint URL | (Reserved; not yet collected) | n/a |
| Counter-photos selected from the booking's existing proof photos (sorter side, post-response) | Sorter's defence in admin review | Contract performance |
| Sorter response text | Admin review + customer transparency | Contract performance |
Dispute case records (complaint text, responses, verdicts) are retained for 6 years from the date the case closes, for the establishment and defence of legal claims (legitimate interests, Art. 6(1)(f); the 6-year period reflects the Limitation Act 1980). Photos submitted as part of a dispute follow the photo schedule in §2.4 (180 days after close + 90 days cold storage).
2.6 Device telemetry + notifications
| Data | Purpose | Lawful basis |
|---|---|---|
| App version, OS version, device model (anonymous beyond your account) | Diagnostic + compatibility | Legitimate interests |
| Push notification token (FCM) per device | Deliver push notifications | Contract performance + your push-permission grant |
| Per-category notification toggle states + quiet hours window | Respect your notification preferences | Contract performance |
| Notification delivery receipts (push ack, email delivery/bounce status from our own mail server, SMS DLR) | Confirm we reached you for time-sensitive events (e.g. dispute response window) | Contract performance |
| Crash reports + error stack traces (PII-minimised) | Diagnose app issues | Legitimate interests |
We use a self-hosted error reporter (GlitchTip) for crash data; reports never include your email, IP address, or any content you typed into the app. Crash reports are retained for 90 days.
Sortr emails do not contain tracking pixels. Email delivery receipts are derived from our own self-hosted mail server's delivery and bounce status — we do not embed open-tracking images or otherwise access information on your device to detect whether you opened an email.
2.7 Audit + compliance logs
We keep an audit log of administrative actions (admin verdicts, dispute state transitions, GDPR erasure events, payout events, etc.) for legitimate-interests + legal-obligation purposes. Audit logs are retained for 6 years from the event, aligned with UK tax and accounting record-keeping periods (Finance Act 1998 Sch 18; Taxes Management Act 1970 s.12B; Companies Act 2006) and the Limitation Act 1980 for the defence of legal claims.
2.8 Product analytics (optional — only if you opt in)
If — and only if — you opt in to analytics, we collect a small amount of usage data to understand how the app is used and to improve it. Analytics events are recorded against a pseudonymous account identifier rather than your name, email or phone. Sortr can link that identifier back to your account (which is how we delete your analytics data on request), but analytics events never contain your name, email, phone, address, precise location or message content, and we never use analytics to make decisions about you. Nothing is collected unless you turn analytics on; you can turn it off again at any time.
| Data | Purpose | Lawful basis |
|---|---|---|
| A pseudonymous account identifier (re-linkable by Sortr only) | Link your own analytics events together so we can measure funnels and feature use | Consent (Art. 6(1)(a) UK GDPR) + PECR reg. 6 |
| Event names (e.g. "opened app", "started a booking", "completed a booking") | Understand which features are used and where users drop off | Consent |
| Non-identifying event details (e.g. task tier, whether a booking is recurring, a star rating, an amount) | Product insight | Consent |
Analytics events never include your name, email, phone, address, precise location, IP address, or anything you type into the app. We do not use analytics for advertising, and we do not sell it. Analytics is processed on our own self-hosted infrastructure in the UK using PostHog — it is not sent to any third-party analytics company.
Retention: analytics events are automatically deleted after 14 months.
Your control: turn analytics off at any time via the Usage analytics setting (reached from your profile). When you turn it off we stop collecting new events immediately and clear the analytics identifier on your device. You can also ask us to delete your existing analytics data (see §6).
2.9 In-app chat
| Data | Purpose | Lawful basis |
|---|---|---|
| Messages you send and receive in a booking's chat thread | Customer–Sorter coordination for the booked task | Contract performance |
| Read markers + timestamps | Show delivery/read state | Contract performance |
Chat is per-booking and closes when the booking reaches a final state. Sortr Resolution staff can view a booking's chat thread when reviewing a dispute or a safety report (legitimate interests: dispute resolution, fraud prevention and user safety). Chat messages are hard-deleted 12 months after they are sent, unless the booking is part of an open or recently closed dispute, in which case they follow the dispute schedule in §2.5. If you exercise your erasure rights, your messages are redacted from the thread.
2.10 Safety features (SOS, live location, share links)
| Data | Purpose | Lawful basis |
|---|---|---|
| SOS event record (time + lat/lng at the moment a Sorter triggers SOS, whether the emergency contact was alerted, admin response) | Respond to a safety emergency; keep a record of the incident | Vital interests (Art. 6(1)(d)) + legitimate interests (Sorter safety, incident record) |
| Live-location samples while a Sorter is on an active booking | Arrival tracking for the customer; safety | Contract performance + legitimate interests (safety) |
| Live-location share-link token, including a one-way hash of the recipient's phone number | Lock a shared tracking link to its intended recipient so a forwarded link does not work | Legitimate interests (preventing forwarded-link abuse) |
Live-location samples are transient: we keep only the latest position (overwritten on each update, refreshed roughly every 90 seconds) while the booking is active; we do not build or retain a historical movement trail. Share links expire and are revoked when the booking ends. SOS event records are retained for 7 years as safety-incident records (establishment/defence of legal claims).
2.11 Sorter compliance (sanctions screening + HMRC reporting)
Sanctions screening. We screen Sorter accounts weekly against the OFSI consolidated list of financial-sanctions targets, comparing name + date of birth. A match never leads to automatic suspension — a human admin reviews every flag (see §12). Lawful basis: legal obligation (financial-sanctions regimes under the Sanctions and Anti-Money Laundering Act 2018) + legitimate interests (we must not make funds available to a designated person).
HMRC digital-platform reporting. As a UK digital platform we are required by the Platform Operators (Due Diligence and Reporting Requirements) Regulations 2023 (SI 2023/817) to report Sorter information to HMRC annually: your identity details, National Insurance Number, address, financial-account identifier, and quarterly earnings and fees. Our first report is due by 31 January 2027. Lawful basis: legal obligation (Art. 6(1)(c)). We collect your NINO before your first payout; if it is outstanding we will remind you, and the regulations require us to withhold payouts or close your account if it is not provided after two reminders (reg. 19).
2.11A If you owe Sortr money (Sorters)
If a dispute outcome or reversal leaves your Sorter balance negative, we process additional data to recover (or, where our Sorter terms provide, write off) the amount due:
| Data | Purpose | Lawful basis |
|---|---|---|
| Negative-balance and recovery records (amount owed, offsets against later earnings, write-off events) | Recovering sums due under the Sorter terms (see Sorter terms §6–§7), including the automatic write-off threshold | Contract performance (Art. 6(1)(b)) + legitimate interests (Art. 6(1)(f) — recovering sums due) |
| Hardship-appeal submissions, including evidence of Universal Credit or equivalent benefit receipt that you choose to provide | Deciding your one-shot hardship appeal fairly | Legitimate interests (Art. 6(1)(f) — operating the hardship concession fairly); you have the right to object (§6) |
Hardship-appeal evidence is processed only for deciding the appeal and is visible only to Sortr Resolution staff. We delete the evidence 12 months after the appeal closes; only the appeal outcome is retained, on the 6-year dispute schedule in §2.5. We recognise that benefit-entitlement information is sensitive financial information and we never use it for any purpose other than the appeal.
2.12 People who aren't Sortr users
We hold limited personal data about some people who never create a Sortr account:
| Who | Data + purpose | Lawful basis | Retention |
|---|---|---|---|
| A Sorter's emergency contact | Name + phone number, used only to send an alert if the Sorter triggers SOS | Vital interests + legitimate interests (Sorter safety) | While nominated by the Sorter |
| A live-location share-link recipient | A one-way hash of the phone number the link was sent to (we keep the SMS delivery record with our SMS provider, Twilio) | Legitimate interests (locking the link to its recipient; preventing forwarded-link abuse) | Until the link expires or the booking ends |
If you are one of these people: Micromat Limited is the controller, your rights in §6 apply to you, and you can contact us at hello@sortr.uk. Sorters must tell their emergency contact they have been nominated and point them to this policy; the share-link SMS and its landing page link here.
2.13 Reviews and ratings
After a completed booking, customers can leave a star rating and a written review of their Sorter. Reviews are personal data of both the reviewer (it identifies you as the author) and the reviewed Sorter (it is an assessment of them and their work).
| Data | Purpose | Lawful basis |
|---|---|---|
| Review text + star rating + reviewer first name | Post-task feedback; public quality signal on the Sorter's profile; review moderation, including detecting fake or incentivised reviews as required by the Digital Markets, Competition and Consumers Act 2024 (Sch. 20 banned practice on fake reviews) | Contract performance (Art. 6(1)(b)) for capturing the review; legitimate interests (Art. 6(1)(f)) for publication on the Sorter's profile and for moderation — you have the right to object (§6) |
What the Sorter sees: the reviewed Sorter can see the review, including your star rating, your review text and your first name. Reviews remain on the Sorter's profile while the Sorter's account is active. If you (the reviewer) delete your account, your reviews are anonymised — the text and rating may remain on the Sorter's profile, but your name and account link are removed.
If you are a Sorter: customer-authored reviews about you arrive from the customer, not from you. This section is the Article 14 notice for that data; your §6 rights (including objection and rectification of inaccurate factual content) apply, and you can report a review you believe is fake, abusive or in breach of our review rules to hello@sortr.uk.
3. Who we share data with (sub-processors)
We share the minimum data required with these sub-processors. Each is contractually bound by GDPR-grade data-processing terms.
| Sub-processor | What we share | Why | Located |
|---|---|---|---|
| Stripe Payments Europe Ltd (Ireland) | Payment method token, payout transfer ids | Payments + Sorter payouts | EEA + UK (Stripe DPA; UK Addendum / UK–US Data Bridge for any US group transfers) |
| Twilio Ireland Ltd | Phone number, SMS body | SMS share links + delivery receipts | Ireland + US (UK Addendum / UK–US Data Bridge) |
| Google Ireland Ltd (Firebase Cloud Messaging) | FCM push token, notification body | Push delivery to Android + iOS | EEA + US (UK Addendum / UK–US Data Bridge) |
| Apple Inc. (APNs, for iOS push) | APNs push token, notification body | Push delivery to iOS | US (UK Addendum / UK–US Data Bridge) |
| OpenWeather Ltd | Postcode-sector-level location | Smart nudge weather context | UK |
| Protomaps (self-hosted tiles) | Tile coordinates only (no user data) | Map rendering | UK (self-hosted) |
Separate controllers we work with. For Sorter identity verification (KYC), Stripe acts as an independent data controller, not our sub-processor: it collects and holds your ID document, selfie and date of birth under its own anti-money-laundering obligations and its own privacy policy (see §2.3). Stripe is our processor only for the payment-token and payout flows in the table above.
For federated sign-in (Sign in with Apple / Sign in with Google, see §2.1A), Apple Inc. and Google each act as an independent data controller for the authentication itself — they operate the login, decide who you are, and process your data under their own privacy policies. This is a different footing from their roles as our push processors: Apple Inc. (APNs) and Google Ireland Ltd (Firebase Cloud Messaging) appear in the sub-processor table above only for delivering push notifications, and those rows do not cover the identity data described here. For federated sign-in we receive the id-token data in §2.1A from them as one controller to another; they are not our processors for it, and a processor DPA does not govern this leg.
Recipients under a legal obligation (not sub-processors — we are legally required to disclose to them):
| Recipient | What + why |
|---|---|
| HMRC | Sorter identity, NINO, address, financial-account identifier, quarterly earnings + fees — annual digital-platform reporting under SI 2023/817 (see §2.11) |
| OFSI / HM Treasury | Reports required under UK financial-sanctions regimes if a screening match is confirmed (see §2.11) |
All other services (database, file storage, email SMTP, error reporting, and product analytics (self-hosted PostHog)) are self-hosted on Sortr-controlled infrastructure in the United Kingdom. Product-analytics data is never shared with PostHog Inc. or any third party.
Other disclosures the law requires or permits. We may also disclose personal data where the law requires or permits it: to police and law-enforcement bodies investigating crime (under the crime-and-taxation provisions of the Data Protection Act 2018, Schedule 2), to courts and tribunals under a court order or in legal proceedings, to our professional advisers and insurers in connection with legal claims, and — if Sortr is sold or restructured — to the prospective buyer under confidentiality obligations, with this policy continuing to apply to your data.
We do not sell your personal data. We do not share your personal data with advertisers, data brokers, or any party for marketing purposes beyond the in-app push / email categories you opt in to (you can opt out of every non-transactional category at any time in the app's Notifications settings).
4. International transfers
Some sub-processors (Twilio, Google, Apple, and Stripe group companies) operate in the United States. Where personal data is transferred to the US, we rely on:
- (a) the UK Extension to the EU-US Data Privacy Framework (the "UK–US Data Bridge", SI 2023/1028) where the recipient holds a current certification covering the UK Extension; and otherwise
- (b) the UK Addendum to the EU Standard Contractual Clauses or the ICO's International Data Transfer Agreement (IDTA), supported by a transfer risk assessment in line with ICO guidance and the data protection test introduced by the Data (Use and Access) Act 2025.
Federated sign-in (identity legs). Signing in with Apple or Google routes identity data to Apple Inc. and Google in the United States as independent controllers, not as our processors (see §2.1A and §3) — a materially different footing from the push-notification legs above, so the processor SCCs in those vendors' DPAs do not cover it. The US-facing identity legs are: the inbound id-token (provider_subject, provider_email, name); the Apple authorizationCode → refresh-token exchange; our outbound Apple /auth/revoke call; and the inbound Apple server-to-server account-delete / consent-revoked channel. For each we rely on the same basis as (a)/(b) above: the UK–US Data Bridge where the recipient holds a current DPF certification with the UK Extension, otherwise the UK Addendum / IDTA supported by a transfer risk assessment.
If you are based in the UK, your data is stored on our UK-based servers. Transfers to the United States happen only when you actively use a feature backed by one of the US sub-processors listed above (e.g. you receive an SMS, you receive a push notification).
5. How long we keep your data
| Category | Retention period | Reason |
|---|---|---|
| Account record (email, name, etc.) | Until you delete your account | Contract performance |
Linked sign-in identity (provider_subject, provider email, Apple relay flag, AES-256-GCM-encrypted Apple refresh token — see §2.1A) |
Until you delete your account or Apple/Google signals delete/revoke; hard-deleted on erasure (including the deferred erasure in §2.1A), not anonymised; the Apple refresh token is destroyed at the same point | Contract performance; erasure (Art. 17). provider_subject is treated as internal linkage and is never included in a data export |
| Bookings + payments + tax-relevant transaction history | 6 years from the booking date | UK tax + accounting record-keeping (FA 1998 Sch 18; TMA 1970 s.12B; Companies Act 2006) |
| Proof-of-work photos (no dispute) | 180 days after the booking reaches its final state | Chargeback evidence window (legitimate interests — defence of legal claims) |
| Proof-of-work + dispute photos (dispute raised) | 180 days after the dispute closes, then 90 days cold storage (audit only), then deleted | Dispute + claims evidence (see §2.4) |
| Dispute case records (text, verdicts) | 6 years from case close | Defence of legal claims (Limitation Act 1980) |
| Reviews + ratings | While the reviewed Sorter account is active; reviewer identity anonymised on reviewer account deletion | Public quality signal + review moderation (see §2.13) |
| Negative-balance + recovery records | 6 years from the balance being settled or written off | Financial record-keeping + defence of legal claims (see §2.11A) |
| Hardship-appeal evidence (incl. benefit-receipt evidence) | 12 months after the appeal closes; outcome retained 6 years on the dispute schedule | Deciding the appeal only (see §2.11A) |
| In-app chat messages | 12 months from sending (dispute schedule applies if the booking is disputed) | Coordination record + dispute evidence |
| SOS event records | 7 years from the event | Safety-incident record; defence of legal claims |
| Live-location samples | Transient — latest position only, overwritten on each update; cleared when the booking ends | Arrival tracking + safety |
| Live-location share-link tokens (incl. recipient phone hash) | Until the link expires or the booking ends | Anti-forwarding lock |
| Sorter emergency contact (name + phone) | While nominated by the Sorter | SOS alerting |
| National Insurance Number | While you remain a Sorter + the period we must keep platform-reporting records under SI 2023/817 | HMRC reporting (see §2.11) |
| Product-analytics events (if you opt in) | 14 months from the event | Behavioural analytics, data-minimised, consent-based |
| Audit + admin-action logs | 6 years from event | Tax/accounting record-keeping + defence of legal claims |
| Notification delivery receipts | 30 days from the event | Diagnostic only |
| Crash reports | 90 days from the event | Diagnostic only |
| Push tokens | Until you remove the device or revoke notification permission | Operational |
When you ask us to delete your account (see §6), we anonymise your booking + dispute records (your name, email, phone, photos hard-deleted; the financial transaction stays, linked to an anonymised user id we cannot reverse). We are required by UK law to keep the financial transaction itself for 6 years.
6. Your rights under UK GDPR
You have the right to:
- Access your personal data (request a copy).
- Rectify inaccurate data.
- Erase your data ("right to be forgotten"). Hard-delete is subject to the financial-retention obligation in §5 above; we anonymise rather than hard-delete the financial transaction.
- Restrict processing.
- Object to processing based on legitimate interests.
- Data portability — export your data in a structured, machine-readable format.
- Lodge a complaint with the UK Information Commissioner's Office (
https://ico.org.uk).
You also have specific rights where decisions about you are made or supported by automated systems — see §12 (Automated decisions and your rights).
To exercise any of these rights, contact us at hello@sortr.uk. We will respond within one month (the UK GDPR statutory timeframe).
You can also export your data + delete your account directly from the app's Profile screen at any time.
7. Children
Sortr is only for people aged 18 or over — both customers and Sorters. Sorter dates of birth are verified through Stripe identity verification; customer accounts require an 18+ self-declaration. We close any under-18 account we discover and delete its data (subject only to the retention obligations in §5). If you believe someone under 18 has created an account, contact hello@sortr.uk.
8. Security
We protect your data with:
- TLS 1.3 + SPKI certificate pinning for all in-app network traffic.
- AES-256 at rest for the user database, the object storage bucket holding proof photos, and the audit log.
- Self-hosted infrastructure under our direct control in the United Kingdom.
- Multi-factor authentication required for every administrative account.
- Encrypted-at-rest backups with 30-day rotation.
9. Cookies + similar technologies
The Sortr app does not use web cookies. We do use the following on-device storage:
flutter_secure_storage(Android Keystore + iOS Keychain) to store your authentication refresh token — strictly necessary, no consent needed.shared_preferencesfor non-secret app preferences — strictly necessary.- The push-notification token your device negotiates with Apple or Google.
- If you opt in to analytics: the PostHog analytics SDK keeps a small on-device queue of pending events plus a stored analytics identifier and your consent choice. This is not strictly necessary and is used only with your consent; the analytics identifier is cleared when you withdraw consent.
We do not use any third-party-hosted analytics, advertising SDKs, or fingerprinting libraries. Our analytics is self-hosted on our own UK infrastructure and runs only if you opt in (see §2.8). Sortr emails contain no tracking pixels or similar technologies — see §2.6.
10. Changes to this policy
If we make material changes to this policy, we will notify you in-app at next launch + send a transactional email.
11. Contact
| Channel | Address |
|---|---|
hello@sortr.uk |
|
| Postal | 6 Carnegie Street, Rushden, NN10 9SN |
| Data Protection Officer (DPO) | Lance James (sole director), privacy@sortr.uk — role currently held by the sole director pending any future appointment |
UK Information Commissioner's Office (regulator): https://ico.org.uk · helpline 0303 123 1113.
12. Automated decisions and your rights
Some Sortr decisions are made or supported by automated systems. This section tells you which ones, what they do, and whether a human makes the final decision — as required by UK GDPR Articles 13(2)(f) and 22A–22D (Articles 22A–22D UK GDPR, inserted by section 80 of the Data (Use and Access) Act 2025 and in force from 5 February 2026).
| System | Who it affects | What it does | Human role |
|---|---|---|---|
| Risk-flagging | Sorters + customers | Flags an account for review on unusual patterns — for Sorters: 3 or more upheld dispute complaints in any 30-day period, or a dispute-loss rate of 0.5% or higher over your last 20+ bookings, or a link-graph collision with another account; for customers: unusual patterns of prior complaints, which may be weighed in dispute review | A flag never suspends an account by itself. A human admin reviews every flag on its merits within 5 working days |
| Dispute evidence scoring | Both parties to a dispute | Scores dispute photo evidence on GPS proximity (within 50m of the booking address), capture-time window, duplicate detection and device-integrity attestation | A score above the threshold can be decisive for the dispute outcome; below it, a Sortr Resolution admin decides. Either party can ask for human review of a score-driven outcome (safeguards below) |
| Graduation gate | Sorters | Determines when the new-Sorter payout hold is removed | Appeals are decided by a human admin |
| Dispatch + feed ordering | Sorters | Orders which available jobs Sorters see | Declining a job has no consequence in the dispatch algorithm, payout tier, graduation gate, or feed access |
| Sanctions-screening flag | Sorters | Weekly name + date-of-birth comparison against the OFSI consolidated list (see §2.11) | Never auto-suspends — a human admin reviews every match |
| Reliability tier + dispatch exclusion | Sorters | Computes a reliability tier from your recent conduct and can exclude you from some dispatch for a period. In plain terms: accepting a job and then dropping it, or not showing up (no-show), lowers your tier; simply declining a job does not — declining has no effect on your tier, dispatch, payout tier, graduation gate or feed access (as in the row above). The tier decays back up over time as your recent conduct improves | This is a solely-automated decision that can significantly affect you, so you have the Article 22C(1)(a)–(c) rights below: meaningful information about the logic, the right to make representations, and human intervention. A Sortr admin can review and override the tier on the merits (contest via the "why this happened" panel; the override requires a stated non-algorithmic factor and a human clearance). Mirrors Sorter terms §10 |
For every significant automated decision, you have the right (Articles 22C–22D) to:
- Be given information about the decision — the in-app "why this happened" panel tells you what triggered it.
- Make representations about the decision — the panel includes a representations form (text + file upload).
- Obtain human intervention — a Sortr admin (not an automated system) will review the decision.
- Contest the decision — through the same panel, then by escalation to our Data Protection Officer (§11) and from there to the ICO.
These rights apply to both customers and Sorters. Sorters have a matching contractual statement in the Sorter terms §10.