Data Retention Schedule

Effective date: 2026-09-02
Version: 1.8

Amendment (2026-09-02, v1.8): Section 7.3 now states that the access and audit log rows PeasyBooking holds in its own database are deleted by the scheduled retention process once they pass the 24-month window (legal holds excepted); Section 7.7's interim status statement is extended to cover that deletion step.
Amendment (2026-08-31, v1.7): Section 7.4 extended to disclose the equivalent minimal record retained when a business that enabled the custom email-domain add-on is deleted (the sending domain's provider registration teardown evidence — opaque identifier only, no domain name), under the same 24-month window, scheduled deletion process, and legal-hold exception.
Amendment (2026-08-31, v1.6): Section 7.4 now discloses the minimal, data-minimized record retained when a business that enabled the SMS add-on is deleted (the provider number's teardown evidence — no phone numbers, no message content), with a 24-month retention window under the same scheduled deletion process and legal-hold exception; Section 7.7's interim status statement covers it. Existing records were minimized (stored phone numbers removed) in the same change.
Amendment (2026-08-16, v1.5): added Section 7.7 disclosing that the automated deletion steps in Sections 7.4 and 7.5 currently run in report-only mode in production, and how a record that becomes due is handled until that changes. Section 3.2 and the guest-facing sections of the Privacy Policy were corrected in the same revision to describe the Marketplace as it is actually built — guest bookings without a consumer account — rather than describing guest accounts, sign-in credentials, and self-serve account closure that PeasyBooking does not currently offer.
Amendment (2026-08-14, v1.4): corrected Section 3 to describe the deletion behaviour that actually exists — history-preserving client Merge rather than an in-product per-client erasure control that the product does not provide — and added a supported, identity-verified manual erasure workflow (Section 3.4) with a response SLA and the legal-hold, tax/accounting, and append-only/WORM carve-outs. Scoped self-serve in-product erasure is disclosed as planned, not yet available.
Amendment (2026-08-02, v1.3): added the bounded, operator-owned lifecycle for ambiguous late-payment evidence and disclosed the minimized 84-month legal-acceptance survivor, its purge-based clock, append-only holds, and verified deletion path.
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). Deletion of an individual record inside an active account is more limited than deletion of the whole account: the product preserves client history rather than erasing client records in place (duplicates are consolidated through Merge, Section 3.1), and erasure of a specific individual's data is handled through the supported, identity-verified manual erasure workflow in Section 3.4 — because the product does not yet provide a self-serve per-client, per-appointment, or per-note erasure control.

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. The Customer controls its records through the product — creating and editing clients, appointments, notes, and similar records, and removing certain records the product exposes a removal control for (for example, a calendar block). PeasyBooking preserves client history rather than deleting client records in place: where two records describe the same person, the product's Merge feature reassigns the duplicate's history to the surviving record and deactivates the duplicate; it does not erase the underlying personal information. The product does not provide a self-serve control to permanently erase an individual client, appointment, or note from active systems. Where erasure of a specific individual's data is required, PeasyBooking provides the identity-verified manual erasure workflow in Section 3.4; deletion of an entire account and all of its data follows Sections 4 and 5. In-product record changes take effect in active systems promptly and then age out of backups as described in Section 6.

3.2 Marketplace guest data. The Marketplace is guest-first: PeasyBooking does not offer consumer accounts, so there is no guest account, login, or password, and a guest's last activity is measured by their last booking rather than by a sign-in that does not exist. What PeasyBooking holds and is responsible for is the marketplace-side record: the booking details a guest provides, their searches and booking-source attribution, reviews, and communications with PeasyBooking. That information is retained while it is needed to operate the marketplace, support disputes, and meet legal obligations, and as a default for up to 24 months following the guest's last booking, after which it is 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. A guest may request earlier deletion at any time as described in the Privacy Policy — no account is required to make the request — 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. Separately, the booking record a provider holds about the guest is that provider's own client record, processed under its instruction and governed by Section 3.1 and the DPA.

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.

3.4 Erasing a specific individual's data — supported manual workflow. PeasyBooking does not currently provide a self-serve, in-product control to erase an individual client record, appointment, or note. Where a specific individual's personal information must be erased from an active account — for example to satisfy a client-deletion request the Customer has verified, or the Customer's own obligations as the responsible organization for its Client Data — PeasyBooking provides a supported, identity-verified manual erasure workflow:

• How to request. The Customer's account owner or an authorized administrator submits a written request to PeasyBooking's Privacy Officer at info@peasybooking.com, identifying the individual and the records to be erased.
• Identity verification. Before performing any erasure, PeasyBooking verifies that the requester is the account owner or an authorized administrator of the Customer that controls the data. PeasyBooking does not act on a request it cannot verify. Because PeasyBooking processes Client Data on the Customer's behalf and under its instructions (Section 1.2), a deletion request that a Customer's own client brings directly to PeasyBooking is routed to that Customer (the responsible organization), which PeasyBooking then supports.
• What is erased. On a verified request, PeasyBooking erases the identified individual's personal information from active systems — for example the client profile and its contact details, appointment and service history detail, notes, and form responses — after which the residual copies in backups age out under Section 6.
• What is carved out. Erasure does not extend to data this Schedule requires be retained: records under a legal hold (Section 9); tax, accounting, and financial records PeasyBooking must keep (Sections 7.1 and 7.6); payment records held by Stripe under its own obligations (Section 7.1); minimized, pseudonymized append-only/WORM evidence such as the legal-acceptance survivor and the provider-teardown and quarantine records (Sections 7.4 and 7.5); and audit and security logs (Section 7.3), which are retained for their defined periods and then deleted or aggregated. Where a carve-out applies, PeasyBooking erases what it lawfully can and identifies what is retained and why.
• Response time (SLA). PeasyBooking acknowledges a manual erasure request without undue delay and completes the erasure — subject only to the carve-outs above — within the statutory response timeframes referenced in Section 1.4, and in any event within 30 days of a verified request, unless a longer period is permitted by law or a legal hold applies.

Planned: scoped self-serve, in-product erasure — carrying the same legal-hold, tax/accounting, and append-only/WORM carve-outs, and covering any personal data captured in point-in-time backup snapshots — is on PeasyBooking's roadmap. Until it ships, the manual workflow in this Section is the supported erasure path; this Schedule will be updated when the in-product control is released.

---

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. The access and audit log rows PeasyBooking holds in its own database are deleted by the scheduled retention process described in Section 7.7 once they pass the 24-month window, unless a documented legal hold (Section 9) requires retention for longer.

7.4 Provider-teardown, late-event, and quarantine 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 or currency. 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 later of teardown resolution or the last attributed late event and is then deleted by a scheduled retention process, unless a documented legal hold (Section 9) requires retention for longer — in which case it returns to the deletion path when the hold is released. The current operating status of this automated deletion is described in Section 7.7.

Where a business enabled the optional SMS add-on, PeasyBooking likewise retains a minimal, data-minimized record of the dedicated phone number's provider teardown when the business is deleted: the opaque provider number identifier and provisioning reference, the deletion instruction it belonged to, the release outcome and which delivery mechanism produced that evidence, and its time. It contains no phone numbers, no message content, and no contact details. It is retained for 24 months after the teardown resolves and is then deleted by the same scheduled retention process, subject to the same legal-hold exception (Section 9). The current operating status of this automated deletion is described in Section 7.7. The same minimal pattern applies where a business enabled the optional custom email-domain add-on: only the opaque provider registration identifier for the sending domain, its release outcome, and its time are retained — no domain name and no message content — under the same 24-month window, deletion process, and legal-hold exception.

If an incoming provider event cannot be attributed safely — for example, because an opaque connected-account reference was reused across business lifecycles — PeasyBooking stores only the event/provider identifiers, event type, timestamps, reason, and authority/generation context in a restricted quarantine; amounts, currency, names, contact details, and payment-method data are excluded. Every quarantine item has a status, accountable operator, review deadline, expiry, append-only activity history, and optional legal hold. An authorized operator must resolve it to the verified teardown record, dismiss it with a reason, extend its review deadline with a reason, or place it on hold. Unheld quarantine items expire and are deleted no later than 24 months after receipt; a resolved item follows the later applicable teardown/late-event clock above. A release of hold resumes, but never resets, the ordinary clock.

7.5 Legal-acceptance evidence after business deletion. The full in-account acceptance receipt is deleted with the business. To preserve narrowly scoped contract evidence, PeasyBooking retains a separate minimized survivor containing the accepted document key, manifest hash, exact document/version/content-hash map, acceptance time, purge time, display locale/market, and acceptance method. It contains no name, email, business name, free text, or payment data. The former business UUID and a one-way acceptor hash remain only as pseudonymous correlation references inside the restricted evidence workflow; neither carries the deleted business profile or the accepting person's direct identity. The retention deadline is 84 months after the later of acceptance or completed business purge, so an old acceptance never becomes immediately due when its business is deleted. Holds and releases are append-only evidence events rather than edits to the survivor. An unheld survivor is deleted by a predicate-safe scheduled process at expiry; a held survivor returns to that deletion path when the hold is released. The current operating status of that scheduled process is described in Section 7.7. Authorized evidence export verifies every archived document's bytes and recomputes the stored manifest before reporting the proof complete.

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

7.7 Status of automated deletion (interim). The scheduled deletion processes described in Sections 7.4 (including the SMS-number teardown record) and 7.5, together with the access and audit log deletion described in Section 7.3, are built, deployed, and run daily, but in production they currently run in report-only mode: each run applies the same predicates, identifies the records that are due, and records what it would delete, without performing the deletion. PeasyBooking will enable automated deletion before the first record in any of these categories becomes due; where a record becomes due before that change is made, it is deleted manually under the same predicates, on the same schedule, and subject to the same legal-hold exception in Section 9. This statement is bound to PeasyBooking's production configuration by an automated release check, so this Schedule cannot describe enforced automated deletion while the deletion step is configured off — or continue to describe a report-only interim after it is switched on.

---

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