# Data Retention Schedule **Effective date:** 2026-06-25 **Version:** 1.0 This Data Retention Schedule (the "**Schedule**") describes how long **PeasyBooking Technologies Inc.** (operating as "**PeasyBooking**", "we", "us"), registered office 150 Evergreen Mount SW, Calgary, AB T2Y 0L8, retains the categories of data it holds, when and how that data is deleted, and the limited circumstances in which deletion is paused. It is governed by the laws of the Province of Alberta and the applicable federal laws of Canada. This Schedule is referenced by, and forms part of the understanding created by, the PeasyBooking **Terms of Service**, the **Privacy Policy**, and the **Data Processing Agreement** (the "**DPA**"). Where this Schedule addresses clinical notes or records-vault (health) data, it is read together with, and is subordinate to, the **Health Data Addendum** signed by the Customer. If there is a direct conflict between this Schedule and a signed agreement between PeasyBooking and a Customer, the signed agreement governs for that Customer. > **Reconciliation status (updated 2026-07-01).** The clinical-records carve-out and the breach-notification role split described in this Schedule are now stated consistently in the master Terms of Service (Section 11), Privacy Policy (Sections 12–13), and DPA (Sections 8 and 10), and the carve-out is **implemented and tested in the production system** (the automated purge process skips any business holding records-vault/clinical data; deletion of such data occurs only through an owner-attested instruction). One residual inconsistency remains: the **summary privacy page published on the website** still describes the 30-day deletion rule without the clinical carve-out and should be corrected when the counsel-approved versions of these documents are published. Capitalized terms not defined here have the meaning given in the Terms of Service, the Privacy Policy, or the DPA. "**Customer**" means a business that holds a PeasyBooking account. "**Customer Data**" means data a Customer or its clients enter into or generate within the service. "**Client Data**" means personal information about a Customer's own clients or patients that PeasyBooking processes on the Customer's behalf and under its instructions. "**PeasyBooking-Controlled Data**" means personal information for which PeasyBooking is itself the responsible organization rather than a processor acting on a Customer's instructions — principally account-holder and staff personal information and marketplace guest data. --- ## 1. How to read this Schedule 1.1 **Two deletion concepts.** This Schedule distinguishes between (a) deletion from **active systems** — the live production database and application, where data is no longer accessible to anyone using the product — and (b) the subsequent **expiry of backups**, which age out on a rolling schedule after active-system deletion (see Section 6). "Permanent deletion" of a record means it has been removed from active systems *and* all backups containing it have expired. 1.2 **Two responsibility roles.** PeasyBooking holds some data as the party responsible for it — **PeasyBooking-Controlled Data**, for example Customer account and billing records, account-holder and staff personal information, and consumer marketplace guest data — and holds other data — principally Client Data and clinical records — *on a Customer's behalf and under its instructions*. The retention rules differ by role, and the Privacy Policy and DPA explain which role applies to which data. 1.3 **This Schedule describes implemented behaviour.** The instruction-based retention rule for clinical and health-records data in Section 5 is **implemented in the production system** (see Section 5.6): the automated purge process will not delete a business that holds records-vault or clinical data, and such data is deleted only on the owner's documented, retention-confirmed instruction. 1.4 **Statutory response timeframes.** Where this Schedule refers to individual rights to export or deletion (see Sections 3.2 and 8), PeasyBooking responds within the statutory timeframes that apply to the request, including the access-and-correction response standard of approximately **45 days** under Alberta's *Personal Information Protection Act* (PIPA), the **30-day** response time under Quebec's private-sector act (Law 25) where it applies, and the timeframes required by PIPEDA, as described more fully in the Privacy Policy. --- ## 2. Data categories covered This Schedule covers the following categories: - **Customer account & business data** — business profile, settings, staff/seat records, login activity. - **Client/CRM data** — a Customer's client contact details, appointment and service history, memberships, and similar booking records (non-clinical). - **Clinical notes & records-vault (health) data** — clinical notes per client/visit and content stored in the encrypted records vault, available only to Customers under a signed **Health Data Addendum**. - **Marketplace guest data** — accounts, searches, bookings, reviews, and marketplace communications of consumers who use the PeasyBooking marketplace. This is PeasyBooking-Controlled Data. - **Account holder & staff data** — personal information of the individuals who hold or are granted access to a Customer account. This is PeasyBooking-Controlled Data. - **Payment records** — subscription billing records held by PeasyBooking, and client-to-clinic payment records processed through Stripe. - **Communications delivery logs** — email and SMS sending/delivery logs held by PeasyBooking and its messaging providers. - **Application & security logs** — operational, access, audit, and security logs. - **Invoices & financial records** — PeasyBooking's own accounting and tax records. - **Backups** — point-in-time and daily backups of the production database. --- ## 3. Active-system retention (while the account is open) 3.1 **General rule.** While a Customer's account is active, Customer Data and Client Data remain available in the live service for as long as the Customer keeps it, subject to product limits and the Customer's own deletion actions. The Customer controls deletion of individual records (for example, removing a client, an appointment, or a note) through the product; such in-product deletions take effect in active systems promptly and then age out of backups as described in Section 6. 3.2 **Marketplace guest data.** A marketplace guest's account, booking history, reviews, and communications are retained by PeasyBooking while the guest's relationship with the marketplace is active, and for a period after the guest's last activity sufficient to operate the marketplace, support disputes, and meet legal obligations. As a default, PeasyBooking retains a guest account and its associated personal information for up to **24 months** following the guest's last booking or sign-in, after which the account and associated personal information are deleted from active systems (with backups aging out under Section 6), except where a longer period is required by law or a legal hold applies. Guests may also request earlier deletion of their account and associated personal information at any time as described in the Privacy Policy, and PeasyBooking responds within the statutory timeframes in Section 1.4; deletion is subject to the residual-data and legal-hold exceptions in this Schedule. 3.3 **Account holder and staff data.** Personal information of account holders and staff is retained while the account is active and as needed to administer access, billing, and security. When an individual is removed from an account, their personal information is deleted from active systems within **90 days**, except for records that must be retained for billing, tax, security, audit, or legal-hold purposes under Sections 7 and 9. --- ## 4. Account closure — ordinary account and business data 4.1 **Access ends on closure.** When a Customer closes its account (or PeasyBooking closes it under the Terms of Service), the Customer's access to the service ends. 4.2 **30-day grace period.** For **ordinary account and business data and non-clinical Client/CRM data**, a **30-day grace period** applies from closure. During this window the data remains recoverable so that an accidental or premature closure can be reversed and so the Customer can complete an export (see Section 8). 4.3 **Deletion after grace.** After the 30-day grace period, ordinary account/business data and non-clinical Client/CRM data are deleted from active systems by PeasyBooking's purge process. Backups containing that data then age out on the rolling schedule in Section 6, after which deletion is permanent. 4.4 **Clinical and health-records data is excluded from this Section.** The 30-day grace-then-delete rule in this Section **does not apply** to clinical notes or records-vault (health) data. That data is governed exclusively by Section 5. This carve-out controls over any contrary statement in the Terms of Service, Privacy Policy, or DPA pending the amendments described in the transitional note above. --- ## 5. Clinical notes and records-vault (health) data — instruction-based retention 5.1 **No fixed-timer deletion.** Clinical notes and encrypted records-vault (health) data are **not** automatically deleted on the 30-day timer described in Section 4. Clinics and other health-information custodians are subject to multi-year statutory and professional record-retention obligations, and PeasyBooking will not unilaterally purge such records on a fixed schedule. 5.2 **Access ends; data is preserved pending instruction.** On account closure, the Customer's live access to clinical and records-vault data ends as for other data. However, PeasyBooking **preserves** that data and deletes it **only on the Customer's documented instruction**, and only after the Customer confirms that its retention, preservation, and legal obligations (including professional and statutory record-retention duties) have been satisfied or otherwise lawfully discharged. 5.3 **Export and transfer first.** Before deletion, the Customer is responsible for exporting, transferring, or otherwise securing its clinical records as required by applicable professional and statutory rules. PeasyBooking will make clinical and records-vault data available for export prior to deletion (see Section 8). 5.4 **End-to-end-encrypted (E2EE) mode.** Where the Customer has enabled the optional end-to-end-encrypted mode for records-vault data, PeasyBooking cannot read the content and holds it only in encrypted form. For such data: - **Deletion may be effected by key destruction (crypto-shredding).** Destroying the encryption keys renders the content permanently unrecoverable, independently of, and without waiting for, the backup age-out cycle in Section 6. Once keys are destroyed, neither PeasyBooking nor the Customer can recover the content even if encrypted copies remain in a backup until that backup expires. - **Export depends on the Customer's keys.** Because PeasyBooking cannot decrypt E2EE content, export of usable (decrypted) content depends on the Customer holding and using its own keys. PeasyBooking can provide the encrypted data but cannot produce decrypted content on the Customer's behalf without those keys. The roles, key-management responsibilities, and consequences of E2EE mode are set out in the Health Data Addendum. 5.5 **Health Data Addendum governs.** The detailed roles, permitted uses, audit, incident-notification, export, retention, destruction, and legal-hold terms for clinical and health-records data are set out in the **Health Data Addendum** and the **DPA**. This Section is a summary; the Health Data Addendum controls in the event of any inconsistency for Customers who have signed it. 5.6 **Implementation status — implemented and tested.** The instruction-based retention behaviour described in this Section is implemented in the production system (as of 2026-06-26, verified 2026-07-01): the automated closure sweep checks each due account and **skips** any business that still holds records-vault or clinical data, logging the retention decision; permanent deletion of such data is possible only through a separate, owner-only instruction in which the owner expressly confirms that the business's retention, preservation, and legal obligations have been satisfied. Both behaviours are covered by automated tests. --- ## 6. Backups 6.1 **Backup mechanism.** PeasyBooking's production database (Google Cloud SQL for PostgreSQL, region northamerica-northeast1, Montréal, Canada) is protected by: - **Automated daily backups**, with the **most recent 30 daily backups retained**; and - **Point-in-time recovery (PITR)** covering an approximately **7-day window**. This configuration was verified against the production infrastructure definition on 2026-07-01 (automated daily backups enabled with 30 retained; point-in-time recovery enabled; deletion protection on). 6.2 **Backups age out on a rolling basis.** Backups are kept only for the windows above and then expire automatically. As newer backups are taken, older ones age out. The daily-backup retention and the PITR window overlap rather than running as two independent clocks. Consequently, once a record is deleted from active systems, copies of it may persist in backups until the **latest** backup containing the record ages out under the 30-retained-daily-backup and approximately-7-day-PITR windows. Depending on when the record was last captured, the maximum time a record remains present in backups after its deletion can approach — and in edge cases slightly exceed — the age of the longest-retained backup that still contains it. After that point, the record is no longer present in backups. 6.3 **Backups are for recovery only.** Backups exist for disaster recovery and integrity, not for ongoing access or analytics. PeasyBooking does not restore individual records from backups on request except where necessary for recovery, security, legal-hold, or comparable purposes. 6.4 **Interaction with deletion.** Because of the backup lifecycle, "permanent deletion" of any at-rest-encrypted record is complete only after both active-system deletion has occurred and all backups containing the record have expired under the windows in Section 6.1. For records held under E2EE mode, destruction of the encryption keys renders content permanently unrecoverable immediately, regardless of whether encrypted copies remain in unexpired backups (see Section 5.4). 6.5 **Restoration re-applies deletions.** A backup restoration is for recovery only; it is not a way to bring back data that was deleted on instruction. After any restoration from backup, PeasyBooking re-applies outstanding deletion instructions and tombstones, so that records deleted before the restore — including instruction-based deletions of health information (Section 5) — do not silently reappear in active systems. --- ## 7. Residual data held outside the core database Even after Customer Data is deleted from the core database, limited related data may persist for defined periods in the following systems, held for legal, accounting, security, or operational reasons. This data is generally limited and is not the Customer's working dataset. 7.1 **Stripe (payment records).** Where a clinic enables the optional online-payments feature, client-to-clinic payments are processed via **Stripe direct charges on the clinic's own connected account**, where the clinic is the merchant of record; and PeasyBooking's own subscription billing is processed through Stripe with PeasyBooking as merchant for its subscription fees. **Stripe (Stripe, Inc., United States/global) processes payment-related data outside Canada**, consistent with the location-of-processing disclosures in the Privacy Policy and DPA and with the Subprocessor List. Stripe retains transaction and payment records under its own policies and applicable financial, anti-fraud, and tax laws. These records persist in Stripe independently of deletion from PeasyBooking's systems. PeasyBooking does not receive, hold, control, or take custody of client-to-clinic funds. (See the Terms of Service for the full payments model.) 7.2 **Email and SMS provider logs.** Transactional and campaign email is delivered through **Resend** (United States); SMS, where enabled, is delivered through **Twilio Inc.** (United States/global). These providers retain sending and delivery logs (such as message metadata, delivery status, and bounce/complaint records) under their own policies; PeasyBooking's own copies of email and SMS delivery logs are retained for up to **18 months** and then deleted or aggregated. Such provider logs may persist after deletion from PeasyBooking's core systems. Message content and consent/suppression records relevant to CASL compliance are addressed in the Terms of Service and Privacy Policy; consent and suppression records are retained for as long as required to demonstrate CASL compliance. 7.3 **Application and security logs.** Operational, access, audit, and security logs are retained for a defined period appropriate to operating and securing the service and to investigating incidents — as a default, up to **12 months** for general operational and application logs and up to **24 months** for access and security/audit logs — after which they are deleted or aggregated. Audit logs of staff access to Client Data and clinical records are retained as described in the DPA and Health Data Addendum. 7.4 **Invoices and financial records.** PeasyBooking retains its own invoices, billing records, and related accounting records (including GST/HST records for its subscription fees) for the periods required by applicable Canadian tax and accounting law. In particular, PeasyBooking retains tax and accounting records for at least the **6-year** record-keeping period required by the Canada Revenue Agency (measured from the end of the relevant tax year), and longer where a specific obligation or legal hold requires. These records are retained regardless of account closure; they are PeasyBooking's records as a business and are retained under its own responsibility. --- ## 8. Exporting data before closure 8.1 **Export before you close.** Customers can export their data before closing an account. PeasyBooking provides export of Client/CRM and booking data in a commonly used format, and, for Customers under a signed Health Data Addendum, export of clinical notes and records-vault content for transfer or retention. For records-vault data held under E2EE mode, export of decrypted content depends on the Customer holding and using its own keys (see Section 5.4). 8.2 **Plan for the grace period.** Because ordinary data is deleted after the 30-day grace period (Section 4), Customers should complete and verify exports during the active period or within that grace window. For clinical and health-records data, export should be completed before instructing deletion under Section 5. 8.3 **Assistance.** On reasonable request before deletion, PeasyBooking will make Customer Data and Client Data available for export as described in the DPA, within the statutory response timeframes referenced in Section 1.4. --- ## 9. Legal holds and suspension of deletion 9.1 **Deletion is suspended where preservation is required.** Notwithstanding any deletion timeline in this Schedule, PeasyBooking will **suspend deletion** of relevant data, and retain it for as long as reasonably necessary, where: - a **legal hold** or preservation obligation applies; - there is an **open payment dispute or chargeback** involving the data; - there is a **pending complaint, claim, or dispute** involving PeasyBooking or the Customer where the data is relevant; or - the data is subject to a **regulatory investigation, audit, lawful request, or court order**. 9.2 **Scope and duration.** A suspension applies only to the data reasonably necessary for the matter and lasts only as long as the obligation or matter requires. When the hold is lifted, the data returns to its ordinary deletion path under this Schedule. 9.3 **Clinical-records interaction.** A legal hold does not override a Customer's own retention duties for clinical records under Section 5; rather, it may extend retention beyond what the Customer would otherwise instruct. --- ## 10. Breach records and notification roles 10.1 **Breach records.** PeasyBooking keeps records of breaches of security safeguards as required by PIPEDA, and retains them for the period required by law. 10.2 **Who notifies whom.** Breach handling reflects the two responsibility roles in Section 1.2: - **Customer-controlled / custodian-controlled data** (Client Data and clinical/records-vault data processed on a Customer's behalf): on becoming aware of a breach affecting such data, PeasyBooking **notifies the affected Customer promptly** and **supports the Customer's** assessment and response. The Customer (as controller or health-information custodian) decides whether and how to notify affected individuals and any applicable regulator. PeasyBooking does not make patient/individual or regulator notifications for this data on its own initiative. - **PeasyBooking-Controlled Data** (account-holder/staff and marketplace guest personal information): PeasyBooking **assesses the breach and makes any notifications required of it by law**, including to affected individuals and to the Office of the Privacy Commissioner of Canada where the legal threshold for notification is met. 10.3 **Other terms govern detail.** The detailed incident-handling, timing, and notification mechanics are set out in the DPA and the Health Data Addendum. The master Privacy Policy (Section 13) now states the role split in this Section correctly. --- ## 11. Changes to this Schedule PeasyBooking may update this Schedule from time to time to reflect changes in its systems, subprocessors, or legal obligations, and will post the new effective date. Where a subprocessor or retention period changes materially, the change will also be reflected in the Privacy Policy and the DPA / Subprocessor List as applicable. --- ## 12. Contact Questions about this Schedule, or about retention, export, or deletion of your data: PeasyBooking Technologies Inc. Attn: Privacy Officer 150 Evergreen Mount SW, Calgary, AB T2Y 0L8 info@peasybooking.com