Trust and security
What the platform does, in enough detail to check
Each section names the control, where it is enforced, and what happens when it fails. Where a fact is not yet confirmed, the page says so instead of guessing.
Verification
Checked before a profile can be found, and again when it lapses
A practitioner cannot appear in search until a person on the trust and safety team has approved their documents.
- 01The practitioner creates an account and completes a profile. At this point it is not searchable.
- 02They upload their professional registration and professional indemnity insurance, each with an issuer, a reference and an expiry date.
- 03A member of the trust and safety team reviews each document in the verification queue and approves or declines it with a recorded note. Every decision is written to an append-only audit trail with who made it and when.
- 04Only when both are approved does the profile enter search.
- 05Ninety days before a credential expires, the practitioner and the team both see it in a countdown. When it expires, the profile leaves search automatically until a renewal is approved.
- Registers checked against
- To be confirmed
- Identity check
- To be confirmed
- What a client sees
- A verified badge on the profile that opens to list each check, when it passed and when it renews, with a link back to this section.
Bookings
A slot is held by the database, not by good intentions
Two bookings for the same practitioner cannot overlap. The rule is a database constraint, so no code path, retry or race can create a double booking.
- Overlap prevention
- A PostgreSQL exclusion constraint on each practitioner’s booked time ranges. A second booking that overlaps an existing one is refused at write, and the client is told the time has gone rather than shown a false confirmation.
- Timezones
- Times are stored as UTC instants and shown in the reader’s timezone, with the zone printed beside them. Practitioners set their hours in their own zone.
- Cancellation
- Each practitioner sets a cancellation window in hours. It is shown on the profile and again before confirming. Cancelling before the window refunds automatically; inside it, the practitioner decides.
- Notifications
- When you book, the practitioner is notified through a database function that takes no recipient: it can only notify the other party to a booking the caller is already in.
Payments
Card details go to Stripe and never reach our servers
Payment is taken by Stripe. The platform receives a confirmation that a payment succeeded, never the card number.
- Card processing
- Stripe. Card data is entered into Stripe’s own fields and does not pass through Wellbeing4me™.
- Where the money sits
- A client’s payment is held by the platform. The platform’s fee is the only part treated as revenue; the rest is recorded as money owed to the practitioner, and the ledger must reconcile to zero before any payout is approved.
- Paying practitioners
- Practitioners are paid out after sessions, to a payout account that has been verified. A payout to an unverified account is refused. Every approval is audited.
- Booking fee for clients
- None. You pay the fee on the profile.
- PCI DSS scope
- To be confirmed
Your information
Who can read what, and what stops anyone else
Access is enforced by row-level security in the database. The application connects as a role the database restricts, so a bug in the application cannot widen what a practitioner can see.
- Practitioner access
- A practitioner can read the bookings, messages and details of their own clients only. Every table holding personal data has row-level security enabled, and a request for another practitioner’s record returns not found, not the record.
- Encryption at rest
- Messages between you and a practitioner are encrypted in the database with AES-256-GCM, using a key held outside the database. A copy of the database is not a copy of the conversations.
- Encryption in transit
- TLS on every connection. The site sends HSTS, so browsers refuse a plain-HTTP connection.
- Uploaded documents
- To be confirmed
- Retention and deletion
- Anything a person created is soft-deleted, so records with a legal retention duty survive a deletion request. You can close your account at any time; records we are required to keep are kept for that period, then removed.
- Retention periods
- To be confirmed
- Data residency
- To be confirmed
- Your requests
- Access, correction and deletion requests are handled as tracked cases with an append-only note trail. Start one at hello@wellbeing4me.com.
How the platform is built
Controls that fail the build when they are missing
Security rules are checked in continuous integration, and a change that removes one cannot be merged. The public list is in the compliance map.
- Passwords
- Hashed with argon2id. Never logged, never returned by the API.
- Sign-in
- Rate limited by IP address and by account, with bot protection verified on the server.
- Sessions
- HttpOnly, Secure cookies on the web. Tokens are never stored in browser storage.
- Input
- Every request is validated against a whitelist of fields; a request with an unexpected field is rejected.
- Queries
- Parameterised only. The unsafe raw-query functions fail the linter.
- Secrets
- Read from the environment at start-up; a secret committed to the repository fails the build.
- Dependencies
- Scanned for known vulnerabilities on every push; a high-severity advisory blocks the merge.
- Headers
- Content Security Policy with no third-party scripts, frame-ancestors none, HSTS, nosniff and a strict referrer policy on every page.
- Independent testing
- To be confirmed
Subprocessors
Who else handles data, and for what
This list names only the services the platform is known to use. Entries marked to be confirmed are being verified before they are published.
- Stripe
- Card payments and practitioner payouts.
- Cloudflare
- Hosting and delivery of the public website, and bot protection on sign-in forms.
- Database hosting
- To be confirmed
- Email delivery
- To be confirmed
- File storage
- To be confirmed
Compliance posture
Mapped to SOC 2 and ISO 27001, not certified against them
Every technical control in the repository is mapped to the SOC 2 criteria and ISO/IEC 27001:2022 Annex A, and each row names the automated check that fails when the control is absent. That map is evidence for a future audit; it is not a certification.
- Certifications held
- To be confirmed
- Privacy law
- To be confirmed
- Data processing agreement
- To be confirmed
Reporting a concern
Tell a person, and say which kind of concern it is
Concerns about a practitioner, a session or someone’s safety are handled first. Mark the subject line “Safety”.
- Safety or conduct
- hello@wellbeing4me.com, subject “Safety”
- Security vulnerability
- To be confirmed
- Breach notification
- To be confirmed