Last updated: 12 September 2026
Relo handles booking, payment, and health-adjacent session data for clients and Pros, and we treat that responsibility as core infrastructure, not an afterthought.
Card details are entered directly into Relo Pay's hosted checkout and never touch Relo's own servers — we are not, and never need to be, PCI DSS certified ourselves, because we don't store or transmit raw card data. A booking is only confirmed once Relo Pay confirms the charge via a cryptographically signed webhook, and payouts to Pros follow the same verified pipeline.
All traffic to the Platform is served over HTTPS. Application data is stored in a managed database with encryption at rest, access is scoped by account role, and every session, booking, and payment state change is recorded as an immutable event — so financial records can be reconstructed and audited, not just trusted.
Identity documents, certifications, and insurance evidence submitted by Pros during onboarding are stored in access-controlled object storage, separate from the application database, and are only readable via short-lived signed URLs generated on demand — they are never publicly listed or linked directly.
Messages, intake forms, and any health-adjacent information shared between a client and a Pro are scoped strictly to the two people in that booking relationship. Exports or deletions can be requested at any time through Support.
Passwords are stored as salted hashes, never in plain text. Sessions are bound to a signed, httpOnly cookie that can't be read by client-side scripts, and resetting your password revokes every other active session on your account.
If you believe you've found a security issue on Relo, please report it to security@relo.co.ukbefore disclosing it publicly. We commit to acknowledging genuine reports promptly and will not pursue action against good-faith security research conducted responsibly and without accessing other users' data.
This page describes the security architecture as actually built. Formal certifications (such as an independent penetration test or SOC 2) have not yet been completed and are a recommended step before handling real payment volume at scale.