Data Processing Agreement
The Schedance ↔ Provider Data Processing Agreement for the Ontario beta, incorporated by reference into the Terms of Service and accepted at sign up. The effective date is the date you accept these terms during onboarding.
Data Processing Agreement (DPA) — Schedance ↔ Provider
**Parties:** This Data Processing Agreement is entered into between **17910797 Canada Inc. (operating as Schedance)** — a corporation incorporated under the *Canada Business Corporations Act* with registered office at 4030 Sheppard Avenue East, Toronto, ON M1S 1S6, Canada ("**Schedance**") and the Provider identified during onboarding ("**Provider**").
**Acceptance method:** This DPA is accepted electronically during account signup, together with the Beta Terms of Service and the Privacy Policy, by a single confirmation that expressly names this DPA. Provider re-affirms this DPA when enabling paid features.
**Effective date:** the date Provider completes signup and confirms acceptance.
---
Recitals
A. Provider operates a movement-services business and has subscribed to the Schedance scheduling and booking platform (the "**Service**"), which is operated by Schedance ("Schedance", "we", "our").
B. Provider collects and otherwise processes personal information about Provider's customers ("**Customers**") in the course of operating Provider's business, including names, contact information, booking history, payment-method tokens, notes, and other personal information.
C. Schedance, in operating the Service, processes Customer personal information on behalf of Provider as a service provider under PIPEDA. Schedance also processes some Customer personal information for Schedance's own purposes in a sub-controller capacity (specifically, the cross-tenant fraud-prevention fingerprints described in Section 5).
D. The parties wish to set out the terms governing Schedance's processing of Customer personal information.
---
1. Definitions
- **"Customer Personal Information"** means personal information that Provider, or Provider's Customers acting on Provider's booking pages, provides to or generates within the Service, that identifies or is reasonably capable of identifying a Customer. - **"PIPEDA"** means the *Personal Information Protection and Electronic Documents Act* (Canada). - **"Provincial Privacy Law"** means AB PIPA and BC PIPA (the Canadian provincial private-sector statutes currently recognized as substantially similar to PIPEDA), and any other Canadian provincial privacy law that becomes applicable to a Customer. Manitoba's PIPITPA has not been proclaimed into force and is excluded; it would be added only if and when it is proclaimed and recognized as substantially similar. - **"Sub-processor"** means a third party engaged by Schedance to process Customer Personal Information on Schedance's behalf. - **"Privacy Policy"** means the Schedance Privacy Policy at [https://schedance.net/legal/privacy](https://schedance.net/legal/privacy). - **"Service"** means the Schedance scheduling and booking platform. - **"Beta Terms"** means the Schedance Beta Terms of Service at [https://schedance.net/legal/terms](https://schedance.net/legal/terms).
Capitalized terms not defined here have the meanings given in the Beta Terms.
---
2. Roles of the parties
### 2.1 Provider as primary organization
Provider is the primary organization (PIPEDA terminology; equivalent to "data controller" under GDPR-style frameworks) for Customer Personal Information. Provider determines the purposes and means of processing.
### 2.2 Schedance as service provider
For most processing, Schedance acts as Provider's service provider under PIPEDA (equivalent to "data processor"). Schedance processes Customer Personal Information **only on Provider's documented instructions** (which include the operation of the Service, integrations Provider configures, and the natural processing inherent in providing the Service).
### 2.3 Schedance as sub-controller for fraud prevention
For the limited purpose of detecting fraud across the Schedance network, Schedance independently determines the purpose and means of processing pseudonymized payment-method fingerprints (with separately-keyed IP and user-agent HMACs maintained for audit and signup-forensics surfaces). Schedance acts in a sub-controller capacity for this processing. Provider acknowledges this and consents on behalf of Provider's Customers (Provider's privacy notice to Customers must reflect this, see Section 4.2). The detail is at [https://schedance.net/legal/fraud-prevention](https://schedance.net/legal/fraud-prevention).
---
3. Scope of processing
### 3.1 Subject matter
Schedance's processing of Customer Personal Information is limited to:
- providing the Service to Provider; - detecting and preventing fraud across the Schedance network (sub-controller capacity); - complying with legal obligations.
### 3.2 Duration
For the duration of Provider's subscription to the Service, plus any retention period in Section 8.
### 3.3 Categories of data subjects
- Customers (students of Provider). - Provider's authorized administrators or staff with access to the Provider account.
### 3.4 Categories of personal information
- Identification: name, email, phone (optional). - Booking: classes booked, attended, refunded. - Payment: Stripe payment-method tokens, last 4, brand, expiration. (Schedance never sees full PAN.) - Notes: customer-entered or Provider-entered booking notes. - Technical (fraud prevention): hashed IP, hashed user-agent, hashed payment-method fingerprint. - Communications: messages exchanged through Schedance support.
### 3.5 Sensitive personal information
Schedance does not require, request, or intend to process sensitive personal information beyond payment data (which is tokenized through Stripe). **Schedance's current version provides no feature for health, medical, or injury information and does not solicit it.** Because some fields are free-text, Schedance cannot technically guarantee that such information will never be entered; any health, medical, injury, or other sensitive information that Provider or a Customer enters into unstructured fields (e.g., booking notes) is processed by Schedance only as ordinary Customer Personal Information on Provider's instructions. Provider must not store such information in those fields without Provider's own additional safeguards and Customer (or, for a minor, parent/guardian) consent, and Provider remains the organization responsible for any such information it chooses to record.
---
4. Provider's obligations
### 4.1 Lawful collection
Provider warrants that Provider has obtained all consents and provided all notices required under PIPEDA and applicable Provincial Privacy Law to authorize Schedance's processing under this DPA. Provider's Customer-facing privacy notice must:
- identify Schedance as Provider's service provider; - describe categories of personal information processed and purposes; - describe Schedance's sub-processors (linking to the Schedance Privacy Policy is acceptable); - describe the cross-tenant fraud-prevention linkage (Provider may link to [https://schedance.net/legal/fraud-prevention](https://schedance.net/legal/fraud-prevention)); - describe US-cloud cross-border transfer (PIPEDA Principle 4.1.3 disclosure); - explain the data subject's rights of access, correction, and complaint.
### 4.2 Provider's privacy notice
Provider's privacy notice to Customers must be available before a Customer transacts on Provider's booking page. Schedance recommends Provider link to or summarize the Schedance Privacy Policy alongside Provider's own.
### 4.3 Provider responsibility for Customer data accuracy
Provider is responsible for ensuring Customer Personal Information in the Provider's account is accurate and current. Schedance does not verify the accuracy of Customer data.
### 4.4 Minors
Where a Customer or class participant is under 16, Provider is responsible for obtaining the consent of the minor's parent or legal guardian before the booking and for reflecting that processing in Provider's own privacy notice. Provider will not provide Schedance with more personal information about a minor than is necessary for the booking, and will use the parent's or guardian's contact details rather than the minor's wherever Provider's workflow allows. Schedance does not require a minor's full date of birth and provides no feature for health or medical information about any Customer (see Section 3.5). Schedance processes minor-related booking data solely as Provider's service provider, on Provider's documented instructions.
---
5. Schedance's obligations
### 5.1 Processing on instructions
Schedance will process Customer Personal Information only on Provider's documented instructions. The Beta Terms, this DPA, and the Privacy Policy collectively constitute Provider's standing instructions.
### 5.2 Confidentiality
Schedance personnel with access to Customer Personal Information are bound by confidentiality obligations equivalent to or stronger than the obligations in this DPA.
### 5.3 Security measures
Schedance will maintain appropriate technical and organizational measures, including:
- TLS 1.2+ in transit; AES-256 at rest; - Row-Level Security (RLS) on database tables; - Access logging and audit-event records; - HMAC-based pseudonymization of fraud-prevention fingerprints; - Webhook signature verification with dual secrets; - Selective webhook-event redaction today, plus a planned logger-level redaction pass for known PII fields before logs leave the application boundary; - A documented offboarding procedure that rotates security secrets whenever any personnel's access ends; - Security audits under Schedance's internal security-audit protocol, conducted at least annually.
### 5.4 Sub-processors
#### 5.4.1 Disclosure
Schedance uses the following sub-processors to operate the Service (current as of effective date; see the Privacy Policy for the current list):
| Sub-processor | Purpose | Location | |---|---|---| | Stripe (Stripe Inc., Stripe Payments Canada Ltd.) | Payment processing, KYC, Connect transfers | US (Canadian entity for some processing) | | Twilio | SMS notifications, phone verification | US | | Cloudflare | DNS, edge proxy, WAF, geofencing | US (global edge) | | Better Stack | Telemetry, error monitoring | US (EU region under review; not contractually assured) | | Render | Application hosting, cron services | US | | Resend | Transactional email | US | | Supabase | Postgres database, auth, storage | US | | Upstash (Upstash, Inc.) | Serverless Redis for API rate-limiting and short-lived session/preview state | US |
#### 5.4.2 Authorization
Provider authorizes the sub-processors listed in 5.4.1 by accepting this DPA. Schedance will notify Provider of new sub-processors at least thirty (30) days before they take effect, with an opportunity for Provider to object. If Provider objects, the parties will work in good faith to find a workable alternative; if no alternative is feasible, Provider may terminate the affected portion of the Service.
#### 5.4.3 Sub-processor obligations
Schedance will impose on each sub-processor terms substantially similar to this DPA, including the security and confidentiality obligations.
### 5.5 Data subject rights
Schedance will assist Provider in responding to Customer requests for access, correction, deletion, or withdrawal of consent. During beta, this is manual; Provider emails `privacy@schedance.net` and Schedance fulfills within 30 days. A self-serve UI is committed for v1.1.
### 5.6 Breach notification
If Schedance becomes aware of a security breach affecting Customer Personal Information, Schedance will notify Provider as soon as feasible (consistent with PIPEDA s. 10.1). The full procedure is maintained in Schedance's internal breach-notification procedure. Schedance will provide reasonable assistance to Provider in meeting Provider's own breach-notification obligations (PIPEDA, Provincial Privacy Law, Stripe, etc.).
### 5.7 Cooperation with regulators
Schedance will cooperate with the OPC, the Alberta and British Columbia Information and Privacy Commissioners, and other Canadian privacy regulators that have jurisdiction, in connection with their investigations or audits of Schedance's processing.
### 5.8 Cross-border transfer (PIPEDA Principle 4.1.3)
Most Schedance sub-processors operate from the United States. Schedance maintains DPAs (or clickwrap equivalents) with each sub-processor. Schedance remains accountable to Provider and to Customers for personal information transferred to sub-processors, regardless of the sub-processor's location.
---
6. Schedance as sub-controller for fraud prevention
### 6.1 Purpose
For successful paid card bookings, Schedance computes a pseudonymized payment-method fingerprint (HMAC of Stripe's payment-method fingerprint, with a dedicated key reserved for payment fingerprints) and matches it across Provider tenants to detect fraud patterns. IP and user-agent signals are HMACed separately for audit/security and provider-signup forensics and are not combined with the payment-method fingerprint. The detail is at [https://schedance.net/legal/fraud-prevention](https://schedance.net/legal/fraud-prevention).
### 6.2 Lawful basis (PIPEDA)
The basis under PIPEDA is meaningful consent, obtained at booking through the Customer-facing disclosure required of Provider in Section 4.1; fraud prevention is additionally documented as a purpose a reasonable person would consider appropriate in the circumstances under PIPEDA s. 5(3), and it is a documented industry-standard practice for marketplace platforms.
### 6.3 Provider's privacy notice must reflect this
Provider's Customer-facing privacy notice must disclose the cross-tenant fraud-prevention linkage. Provider may link to or paraphrase [https://schedance.net/legal/fraud-prevention](https://schedance.net/legal/fraud-prevention).
### 6.4 Retention
Up to 18 months from a Customer's last paid transaction, or 90 days post-account-closure, whichever is sooner. These are target retention periods; until the corresponding automated purge jobs ship, Schedance enforces them by operator review/manual deletion and treats automation as a pre-scale task.
---
7. International transfers
Section 5.8 governs. PIPEDA Principle 4.1.3 (accountability) is the framework.
---
8. Data return and deletion on termination
### 8.1 Provider termination
On termination of Provider's subscription:
- Provider has access to data export tools for thirty (30) days after termination. - After thirty (30) days, Schedance will delete or de-identify Customer Personal Information that Schedance holds, except: (a) data Schedance is required to retain by law (tax records: 6 years from the end of the last taxation year, per *Income Tax Act* s. 230; PIPEDA breach records: 24 months); (b) data Schedance retains for Schedance's own purposes (e.g., fraud-prevention fingerprints, in the sub-controller capacity); and (c) aggregated, de-identified analytics data.
### 8.2 Backups
Backup snapshots roll off on the standard 35-day cycle. Schedance will not restore deleted Customer Personal Information from backup absent legal hold or Provider's specific request.
### 8.3 Sub-processor data return/deletion
Schedance will instruct sub-processors to delete Customer Personal Information per their respective DPAs.
---
9. Audit rights
Provider may, upon thirty (30) days written notice and at Provider's expense, audit Schedance's compliance with this DPA. Audits are limited to once per year and must be scoped to information reasonably necessary to verify compliance. Schedance may, in lieu of an in-person audit, provide a recent third-party audit report (e.g., SOC 2 Type II) once available, or completed reports under the internal security-audit protocol.
---
10. Liability
The liability provisions of the Beta Terms apply to this DPA. Nothing in this DPA expands or contracts the liability framework of the Beta Terms.
---
11. Term and termination
This DPA is effective on the date Provider accepts it during onboarding and continues for as long as Provider has a subscription to the Service. Sections that by their nature should survive termination will survive (Sections 5.5, 5.6, 5.7, 6, 7, 8, 9, 10, 12).
---
12. General
### 12.1 Order of precedence
In the event of conflict between this DPA, the Beta Terms, and the Privacy Policy:
1. The DPA controls for matters specifically governed by the DPA (data processing). 2. The Beta Terms control for all other matters. 3. The Privacy Policy is informational; it does not override the DPA or Beta Terms but is incorporated by reference.
### 12.2 Modifications
Schedance may modify this DPA in line with the Beta Terms unilateral-amendment clause. Material modifications require notice as described in the Beta Terms.
### 12.3 Governing law
This DPA is governed by the laws of the Province of Ontario and the federal laws of Canada applicable in Ontario. Disputes are resolved per Section 14 of the Beta Terms.
### 12.4 Notices
Any notice under this DPA may be given by email to `privacy@schedance.net` (Schedance) or to Provider's account email (Provider).
---
**Acceptance.** By confirming acceptance during signup — a single confirmation covering the Beta Terms, the Privacy Policy, and this DPA — Provider accepts this DPA. Acceptance takes effect on the date of that confirmation, and Schedance retains records sufficient to evidence which version of this DPA was in effect on that date.
---
Appendix A — Sub-processor list (kept current via the Privacy Policy)
See Section 5.1 of the Privacy Policy at [https://schedance.net/legal/privacy](https://schedance.net/legal/privacy) for the current sub-processor list. The Privacy Policy is updated when sub-processors change; that update, together with the notice described in Section 5.4.2, constitutes notice of the change.
Appendix B — Sub-processor obligations attestation
Schedance maintains attestations of compliance for each sub-processor:
- **Stripe:** Stripe DPA + SOC 1, SOC 2 Type II + Stripe Connected Account Agreement - **Twilio:** Twilio DPA + SOC 2 Type II - **Cloudflare:** Cloudflare DPA + SOC 2 Type II + ISO 27001 - **Better Stack:** Better Stack DPA + SOC 2 Type II (current as of 2026-04 review) - **Render:** Render DPA + SOC 2 Type II - **Resend:** Resend DPA + SOC 2 Type I (Type II in progress) - **Supabase:** Supabase DPA + SOC 2 Type II + HIPAA-eligible posture available - **Upstash:** Upstash DPA + sub-processor list (retained internally); SOC 2 status to be confirmed
The attestations are maintained internally and made available to Provider on request.