Legal
Data Processing Agreement
What Runday owes you, as the business whose client records we hold.
Last updated: 4 October 2026 (draft)
Draft, not yet in force
Draft. This is the agreement Law 25 §18.3 and PIPEDA expect between a business and a service provider handling personal information on its behalf. It needs a lawyer's review before it is offered as a binding contract.
Items highlighted like this are unresolved.
Showing: United States (detected from your connection, US).
Location detection is a convenience only. Your actual rights depend on where you live, not on what this page guessed.
1. Why this document exists
The Privacy Policy explains what Runday does with personal information. The Terms set out what you agree to. This document is the missing third piece: what we owe you about the personal information you put into Runday about your clients.
When your client's name and phone number go into Runday, you remain the one responsible for that person. We hold it for you. Canadian privacy law expects that relationship to be written down rather than assumed, and this is where it is written down.
2. Who is who
- You: the business using Runday. You decide what client information is collected and why. You are accountable to your own clients for it.
- Runday: the service provider. We process that information only to provide the service to you, and only as this agreement allows.
For information you give us about yourself and your staff (account details, billing, staff records), we are directly responsible, and the Privacy Policy governs it.
3. What we process, and why
Only what the product needs to work: client names and contact details, appointment and walk-in records, services performed, sale amounts, tips, and the commission calculated from them, plus any notes your staff choose to write.
We process it to run the platform for you, to support you when you ask, to keep the service secure, and to meet legal obligations. Nothing else. Specifically, we do not use your clients' information for our own marketing, we do not sell it, and we do not use it to train models.
4. What we commit to
- Process your clients' information only to provide the service, or where the law compels us
- Keep it confidential, and limit internal access to people who need it to do their job
- Maintain the safeguards described in section 5, and not materially weaken them while you are a customer
- Tell you about a confidentiality incident affecting your data, per section 8
- Help you respond when one of your clients exercises a right, per section 7
- Return or delete the data when you leave, per section 9
5. How it is protected
These are the measures actually in place today, not aspirations:
- Encrypted in transit over HTTPS/TLS, and at rest by our hosting providers
- Row-level security in the database, so your records are unreachable from another business's account as a property of the data layer rather than a UI restriction
- Passwords hashed by our authentication provider; never stored readably
- Staff logins you create must be changed by that staff member on first use
- Rate limiting on public endpoints, and file-type validation on uploads
- Not yet in place: mandatory multi-factor authentication, formal access logging, and independent security testing.
6. Who else touches it
Runday uses the third parties below. Each is bound to protect the information and to use it only to provide their service to us. A new one is added to this list before it starts handling your clients' information, not afterwards, and the same applies when a processor already on this list begins handling a category it did not before.
| Provider | What for | Where | What it can see |
|---|---|---|---|
| Supabase | Database, authentication, and file storage, the primary system of record | Canada (AWS ca-central-1, Montreal) | All account, staff, client, appointment, sale and commission records; staff photos; photos of a client’s finished haircut, taken only with the client’s agreement and kept private |
| DigitalOcean | Application server hosting for rundays.ca | Canada (Toronto) | Data in transit while pages are rendered, and the database backups: a full copy taken nightly, of which only the last two stay on the server, plus DigitalOcean’s own weekly copies of the server, kept 4 weeks; all of it is gone within 30 days of an account being deleted |
| Cloudflare | DNS, TLS termination, and protection against abuse | Global edge network, routed via the nearest location | IP address and request metadata in transit; on the login page and the online booking page, also the browser signals its security check (Turnstile) reads to tell a person from an automated script. For a signed-in person, Cloudflare also tells Runday the approximate city of the request (never the IP address), shown in that person’s own list of signed-in devices and kept only while the device stays signed in |
| Stripe | Subscription billing for Runday itself; for a Business User who turns them on, deposits and cards on file taken from its clients at online booking, into the Business User’s own Stripe account (Stripe Connect; Runday takes nothing); and, for a Runday partner who chooses it, paying their commissions into their bank account (Stripe Connect). Not active yet: paid plans begin when Runday opens to shops at the start of summer 2027, and until then no payment path is reachable, so Stripe currently receives nothing | United States | Nothing today. Once paid plans begin: billing contact and payment method. Card numbers are handled by Stripe and never reach Runday. For a Business User’s client paying a deposit or saving a card: their name, email address and phone, the service and the amount; the card itself is typed on Stripe’s page and never reaches Runday. For a partner paid through Stripe: their email address, and the amount of each payment; Stripe itself collects their identity and bank details, under its own agreement with them, and Runday keeps only their Stripe account number and whether it can receive payments |
| Resend | Email: account confirmation, password reset, staff invitations, the reminder before a subscription’s first charge, the owner’s optional Monday summary, the one confirmation sent to someone who joins the waitlist, the notice to Runday’s founders that an idea posted on the public roadmap is waiting for review, the two emails to a founding shop (its welcome, and the one when its founding price becomes permanent), the notice to the founders of a founding shop’s first payment, the problems Business Users report from inside the application, sent to the founders, the notice to a signed-in person of a sign-in to their account from a new device (the device, the approximate city and the time, never the IP address), the Runday Partners programme (a partner’s sign-in code, an application sent to the founders and its receipt to the applicant, the acceptance or decline, the monthly list of payments to make sent to the founders, and each payment’s receipt to the partner), the emails about a team member’s time off (to the owner and the location’s manager when a request is made or an absence declared, to the team member when their request is decided; on by default, and each person and the business can turn them off), and, only for a business that turns them on, the emails sent to its clients about their own appointments in the business’s name (a confirmation, a change or cancellation notice, and a reminder) | United States | Business User email address and the contents of those messages. The Monday summary carries the business’s own weekly totals and staff first names, never a client’s name or contact details. The waitlist confirmation carries the name and email address the person entered. The roadmap notice carries only the idea’s title and details as typed, sent to the founders; the form asks for no name or contact. The founding shop emails carry the business’s name and founding spot number; the first-payment notice to the founders adds the owner’s name and email address. A problem report carries the message as the person typed it, the address of the page it was sent from (never its search terms), the business’s name, the sender’s email address and role, and their browser type; the form asks them to leave out any client’s name or contact details. An email about a team member’s time off carries the recipient’s email address, the team member’s name, the kind of time off (vacation or absence), its dates, the note they typed if any (a note on an absence can touch on health, which is why the form never requires one) and, to the team member, the decision and the note the shop added. An email to a business’s client carries that client’s first name and email address, the appointment (date, time, service, the staff member’s first name), the business’s name, address, phone and cancellation policy, and the client’s private link to change or cancel it; it is sent only when the business has turned these emails on. A partner application carries the name, email address, language, kind, organisation, link and text the person entered; the partner emails carry the partner’s name, their referral link, and for a payment its amount and taxes, where it went (the Interac email, or Stripe) and its reference; the founders’ monthly list adds each partner’s amount with its taxes, and a notice when a Stripe payment did not go. None of them names a shop’s client |
| Google Analytics | Website measurement on the public marketing site | United States | Pseudonymous usage data. Only loaded for visitors who accept analytics cookies, and never present in the signed-in application |
| Sentry | Error and performance monitoring for the application, on the server and in the browser, so a broken checkout or a failed webhook is caught before a Business User has to report it | United States | Error messages and stack traces; the address of the page or request involved, with search terms and other query parameters removed before sending; browser and device type; and load-time measurements for about 1 in 10 page loads and requests. Not collected: IP addresses, cookies, request headers, form or request contents, or who was signed in |
| PostHog | Product usage analytics inside the application, such as which onboarding step a Business User stops at. Not active yet: wired in code, but no account exists and no key is configured, so nothing is sent | United States (PostHog also offers EU-only hosting; not yet decided which region the account will use) | In the browser, only for Business Users who accept analytics cookies: which screens they visit (search terms removed from the address) and named events such as finishing an onboarding step. From the server, without a cookie and tied to the business rather than a person: named events such as a completed checkout with its sale total, or a new location added. Never a client's own name, phone, or appointment details; clicks, screen recordings and page contents are not captured |
| Twilio | Text message reminders sent to a business’s clients about their own appointments, only for a business that turns this paid option on. Not active yet: no account exists and no text has been sent, so Twilio currently receives nothing | United States | Nothing today. Once active: the client’s phone number and the text itself, which gives the business’s name, the date and time of the appointment, the client’s private link to change or cancel it, and how to stop these texts. Never the client’s name, the service, a staff member’s name or any note. Runday deletes each message from Twilio once it has been delivered or has failed |
We will tell you before a new subprocessor starts handling your clients' information, and you may object. If you object and we cannot offer a reasonable alternative, you can export everything and close your account rather than be moved onto a processor you did not accept.
We have deliberately not fixed a number of days' advance notice yet. Runday has not opened to shops and is still adding integrations, and a fixed window we would miss repeatedly is worth less to you than one we can keep. A specific period, with the usual exception for replacing a processor in an emergency, will be set when paid accounts open at the start of summer 2027. The commitment to tell you, and your right to object, apply now regardless.
7. Where it is held, and helping with requests
Your clients' records are stored in Canada. The database is in Montreal and the application server is in Toronto, which is inside Canada but outside Québec. Some information still leaves the country: providers including Stripe, Resend, Sentry, and Google Analytics operate in the United States. Section 6 gives the detail, and the Privacy Policy explains what that means. You should know this before you decide Runday is appropriate for your clients.
Law 25 requires a privacy impact assessment before personal information is communicated outside Québec. One has been written for the transfers that remain, but its conclusions are not yet decided. This affects you as well as us, since you are the one accountable to your clients.
When one of your clients asks to see, correct, delete, or receive a copy of their information, that request goes to you, because they are your client. We will give you what you need to answer it, at no charge and within a reasonable time. If a request reaches us directly, we will point them to you rather than act on it ourselves.
8. If something goes wrong
If your clients' information is accessed, disclosed, or lost without authorisation, we will tell you within 72 hours of becoming aware, with what we know: what happened, what data was involved, what we are doing, and what we suggest you do.
If we do not have the full picture by then, you get what we have on time and the rest as it comes. A complete report that arrives late is worse for you than an incomplete one that arrives while you can still act on it.
We will tell you even where we judge the risk to be low, because that assessment is yours to make for your own clients, not ours to make for you.
9. When you leave
You can export everything at any time from Settings, as a single file, at no cost and without asking us. Deleting your account removes your clients' records from our active systems immediately, with no exception carved out for them. Backups age out on their own cycle within 30 days. Only our own accounting records, meaning what you paid us, are kept afterwards, for the six years Canadian tax law requires.
Because the export is self-serve, there is no window in which you depend on us to hand your data back. Take it before you delete the account and nothing is lost.
10. Term and precedence
This agreement applies for as long as you use Runday, and its confidentiality and deletion obligations continue afterwards until they have been carried out. Where it conflicts with the Terms of Service on the handling of your clients' personal information, this document governs.
11. If you are outside Canada
To be written: United States, covering state-level processor terms and service provider obligations.
12. Contact
- Runday, operated from Québec, Canada
- Privacy Officer (Olivier Morin): [email protected]
- Runday is operated by Olivier Morin, an individual based in Québec, Canada. There is no registered company behind it yet, so you are contracting with that individual. A registered entity name and business address will replace this once Runday incorporates.
See also our Privacy Policy, Confidentiality Policy, Cookie Policy, and Terms of Service.