Data Retention Schedule

Effective date: 2026-07-29
Version: 1.2

Amendment (2026-07-29): Section 7.4 corrected — the provider-teardown record is described as data-minimized (pseudonymous) rather than "PII-free": it retains an opaque connected-account reference and internal record identifiers, which are pseudonymous identifiers, not anonymous data. The same section now also states the legal-hold exception under which deletion is paused.
Amendment (2026-07-21): clinical/health-data clauses removed following the medical de-scope; PeasyBooking no longer offers clinical features. All business data now follows the single standard deletion lifecycle in Section 4, and owner-initiated immediate deletion is described in Section 5.

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"). 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.

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 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 — 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 deletion lifecycle in Section 4 is implemented in the production system: after account closure and the 30-day grace period, the automated purge process permanently deletes the business's data from active systems. Earlier, owner-initiated deletion requires the owner's documented instruction confirming that the business's retention, preservation, and legal-hold obligations have been satisfied (see Section 5).

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, notes, form responses, and similar booking records.
• 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-business 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 all account, business, and 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, the account's business data and Client/CRM data are permanently deleted from active systems by PeasyBooking's automated purge process. Backups containing that data then age out on the rolling schedule in Section 6, after which deletion is permanent. This rule applies uniformly to every closed account, subject only to the legal-hold exceptions in Section 9 and the residual data described in Section 7.

---

5. Owner-initiated deletion (immediate purge)

5.1 Deletion on instruction. A Customer's owner may instruct permanent deletion of the business's account and data without waiting for the 30-day grace period in Section 4. Before PeasyBooking acts on such an instruction, the owner must expressly confirm that the business's retention, preservation, and legal-hold obligations have been satisfied or otherwise lawfully discharged. PeasyBooking acts on the documented instruction only; the Customer remains responsible for determining and meeting any record-retention duties that apply to its business.

5.2 Export and transfer first. Before instructing deletion, the Customer is responsible for exporting, transferring, or otherwise securing any records it needs to keep. PeasyBooking will make the Customer's data available for export prior to deletion (see Section 8).

5.3 Implementation status. The standard closure lifecycle (Section 4) and the owner-attested immediate deletion described in this Section are implemented in the production system: the automated closure sweep permanently deletes each due account after its grace period, and immediate deletion is available only through a separate, owner-only instruction containing the confirmation described in Section 5.1.

---

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.1.1 Where backups are stored. While the production database itself runs in Montréal, Canada, its automated backups and point-in-time-recovery copies are stored in the United States, in Google Cloud's us multi-region (the Cloud SQL default backup location for this instance). This applies to every customer, including customers in Canada. Backup copies are used for disaster recovery only (Section 6.3) and expire on the rolling schedule in Section 6.2. This location is disclosed in the Privacy Policy, the DPA, the Subprocessor List, and the residency acknowledgment recorded at signup.

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 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.

6.5 Restoration re-applies deletions (procedure and its basis). A backup restoration is for recovery only; it is not a way to bring back data that was deleted on instruction. When an account is purged, PeasyBooking records a minimal deletion marker ("tombstone") in an append-only store held outside the database that a restoration would restore — so the evidence that a deletion happened survives a restoration to a point before it. PeasyBooking's restore procedure requires, before a restored copy serves any traffic: reading those tombstones, re-applying the recorded deletions to the restored copy, and not serving the copy at all if the tombstone store cannot be read. This replay procedure is implemented and tested at the component level; until it has additionally been demonstrated in a full end-to-end restore exercise, PeasyBooking describes it as its operating procedure rather than as an independently verified guarantee.

6.6 Recovery-copy matrix. Each mechanism that can hold a copy of a record is distinct — different location, different retention clock, different deletion behaviour. This matrix is the authoritative mapping; no statement elsewhere in this Schedule groups unlike mechanisms under one rule.

6.7 What PeasyBooking does not claim. The production database is a single-zone instance in one region. There is no cross-region replica and no automatic failover; recovery from a zone or instance failure is restoration from the backups above. A timed restore drill (2026-07) measured restoring the database itself in under ten minutes; end-to-end recovery time to a fully serving application, and any regional-failover scenario, have not been measured, and PeasyBooking does not represent an availability or recovery-time guarantee beyond this Schedule's description of the mechanisms that exist.

---

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 business enables the optional online-payments feature, client-to-business payments are processed via Stripe direct charges on the business's own connected account, where the business 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-business 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 are retained as described in the DPA.

7.4 Provider-teardown and late-event records. When a business that enabled online payments is deleted, PeasyBooking retains a minimal, data-minimized record of the Stripe Connect teardown: the opaque connected-account reference, the deletion instruction it belonged to, the teardown outcome and its time, the dispute cutoff checked at the provider before deletion, and counts/types/times of any provider events that arrive after deletion. The record contains pseudonymous identifiers only — no names, no contact details, no amounts. This record exists so that a post-closure dispute, refund, or chargeback event can still be explained and correlated (the merchant remains responsible for such events in its own Stripe account under the direct-charges model). It is retained for 24 months after the teardown resolves and is then deleted by a scheduled retention process, unless a documented legal hold (Section 9) requires retention for longer — in which case it is deleted when the hold is released.

7.5 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.

8.2 Plan for the grace period. Because 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. Where a Customer intends to instruct immediate deletion under Section 5, export should be completed before giving the instruction.

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 Interaction with owner-instructed deletion. A legal hold suspends deletion notwithstanding an owner's deletion instruction under Section 5, and may extend retention beyond what the Customer would otherwise instruct; deletion resumes when the hold is lifted.

---

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 data (Client 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) decides whether and how to notify affected individuals and any applicable regulator. PeasyBooking does not make 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. The master Privacy Policy (Section 13) 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