Vereli Trust & Security
This page describes how the Vereli wedding directory and gift registry protect the information people give us, where it lives, and which other companies handle it. It goes with the Privacy Policy, which says what we collect and why.
Where your data lives
Australia. Vereli's database and file storage (Supabase) run in the Sydney region, and our web hosting (Vercel) runs in Sydney. Email is the exception: our email delivery provider (Resend) processes messages in Ireland, because it offers no Australian region. Enquiries and sign-in emails pass through it on the way to the person they are for.
How your data is protected
- Encryption in transit and at rest. All connections use TLS. Database-level encryption at rest is managed by Supabase.
- Each account only sees its own data, enforced at the database. Row-level security policies mean one business's or couple's data is not visible to another; this is enforced by Postgres itself, not only by application code, and a cross-account isolation test runs in our checks on every change to the database before it can ship.
- Registries are private until published. A registry is a draft until the couple publishes it. Its link is long and random (it cannot be guessed from the couple's names or wedding date), it is kept out of search results and out of our sitemap, and unpublishing takes it down at once.
- No payment details and no delivery address are collected. Vereli does not take payment or hold money through the directory or registry, and asks for neither a card nor a home address. Gift links go to the retailer's own website.
- Sign-in by emailed link, with no password to steal. A link works once, and the session cookie it sets is not readable by scripts on the page.
- Secrets stay on the server. Service credentials and keys are never sent to a browser, and abuse limits use one-way keyed codes, not addresses.
- No AI reads or writes your enquiry. The wedding directory and registry do not use AI to read, reply to or generate any message today.
Sub-processors
Every third party that processes personal information in the course of running the wedding directory and registry, and what it is used for. It matches the list of providers in the Privacy Policy.
| Sub-processor | Purpose | Data involved | Location |
|---|---|---|---|
| Supabase | Database, file storage (business photos) and sign-in | Everything Vereli holds for the wedding services | Sydney, Australia |
| Vercel | Application hosting | Application traffic; no persistent personal data storage | Sydney, Australia (syd1, re-checked 3 September 2026; a response header records where a request was served, so this is worth re-confirming against the project's region setting) |
| Resend | Email delivery: sign-in links, an enquiry passed to a wedding business, and notices about a report or a removal | A person's email address and the message content (for an enquiry: name, email, optional wedding date and message) | Ireland (no Australian region exists for email delivery) |
| Cloudflare (Turnstile) | Bot check on the public enquiry form, to tell a person from a script | The visitor's IP address and browser signals, seen by Cloudflare when the check loads in their browser. Our server sends Cloudflare only the check's result, never a name, email or message | Global network; a request may be handled outside Australia |
| Google (sign-in) | Optional "Continue with Google" sign-in for wedding businesses. Not used unless the person chooses it | Name, email address and whether Google has verified the address, passed to us by Google. Google learns that the person signed in to Vereli; nothing about a listing or an enquiry | Global network; may be handled outside Australia |
| Link-safety service (provider to be named when chosen) | Checks the web address of a gift link against known-dangerous sites | The web address only; never a name or email. Nothing is sent if the check is switched off | To be stated when the provider is chosen |
| Ahrefs | Website analytics on Vereli's own public pages only | Page views. Cookieless, and no personal data is collected | Singapore-headquartered |
| Vercel Speed Insights | Page-performance measurement (Core Web Vitals) on public pages | Anonymous performance timings. No personal data, no cookies | Same provider as the hosting row |
We use each of these only where we need it to run the service: storing information, delivering the emails people are meant to receive, checking that a person and not a script is using a form, and, if someone chooses it, signing them in. Each is sent only what that task needs.
Sending information to a provider outside Australia is a cross-border disclosure under Australian privacy law, and Vereli remains accountable for how that provider handles it. Where a provider offers a choice of region, we choose the more privacy-protective one rather than the default.
Data retention
This matches the Privacy Policy. Some deletion is automatic today and some is not yet, and the policy says which.
| What | Kept | Automatic today? |
|---|---|---|
| A registry you have not published | Deleted 12 months after the wedding date, or 12 months after the last edit if no date was given | Yes |
| A registry you have published | Until you delete it, which you can do yourself at any time | On your action |
| An enquiry you sent | We delete our copy 90 days after the enquiry (later if you enquired again more recently); the business's own copy is theirs | Yes |
| A vendor listing | While listed; taken down when removed, and the rest deleted within 30 days | Takedown yes; clean-up by hand |
| A report | Deleted 12 months after it is closed; an open report is not deleted | Yes |
| Feedback | Deleted 12 months after it was sent | Yes |
Incident and breach response
This describes Vereli's intended process. It has not yet been exercised against a real incident.
- Detection. Structured logging and alerting on known failure signals are the first line of detection. A breach may also be reported by a user or a sub-processor.
- Triage. Assessed within a target of 1 hour of detection during business hours: is personal information actually exposed, to whom, and how much.
- Containment. The specific access path or defect is closed first; root-cause analysis follows, not the other way around.
- Notification. Affected people are told, within a target of 72 hours of confirmation, what happened, what information was involved and what we are doing about it. Where the Notifiable Data Breaches scheme applies, the Office of the Australian Information Commissioner is notified as that scheme requires.
- Post-incident. A written postmortem for any incident that reached containment: root cause, what was affected, and what changed to prevent it recurring.
Service availability
The directory and registry are free and provided as they are. We aim to keep them available but do not promise a level of uptime.