Version: 2026-09-06

Effective date: 2026-09-06 for a Customer that accepts an Agreement incorporating this version; for an existing Customer, the later date on which this version becomes binding under section 19.

Publication URL: https://www.mydatabaseapp.com/data-processing-terms.html

Publication status: Final English master approved for publication and adoption. Production publication and Customer-specific binding events remain subject to the existing finite deployment verification and adoption records; this file alone is not evidence that a particular Customer accepted it.

Provider: Database LLC ("Database")

Customer: The person or legal entity that has accepted the Database Terms of Service, an order, or another agreement for the Services ("Customer").

These Booking Data Processing Terms (the "Data Processing Terms" or "DPT") form part of the agreement between Customer and Database governing Customer's use of the Database appointment, booking, scheduling, client-management, and related transactional-notification services (the "Agreement"). They take effect for a Customer through the applicable adoption mechanism in section 19. If these DPT conflict with the Agreement on the processing of Customer Personal Data, these DPT control.

These DPT allocate data-protection responsibilities. They do not state that any law applies where its territorial, entity, threshold, consumer, or processing predicates are not met.

1. Definitions

  1. Applicable Data Protection Law means a law that applies to the Processing covered by these DPT, including, when applicable, the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA"), the Florida Digital Bill of Rights ("FDBR"), Regulation (EU) 2016/679 ("EU GDPR"), and the United Kingdom GDPR and Data Protection Act 2018 ("UK Data Protection Law").
  2. Customer Personal Data means Personal Data that Database Processes on Customer's behalf through the Services, including Booking Data described in Annex 1. It excludes information for which Database determines an independent purpose and means and identifies that separate role in an applicable privacy notice.
  3. Booking Data means Personal Data submitted by or for an individual to request, create, manage, communicate about, or document an appointment with Customer through the Services.
  4. Personal Data includes "personal data," "personal information," and analogous information protected by Applicable Data Protection Law.
  5. Process and Processing have the meanings assigned by Applicable Data Protection Law.
  6. Controller includes a "business" under the CCPA and a "controller" under the FDBR.
  7. Processor includes a "service provider" or "contractor" under the CCPA where the corresponding statutory requirements are satisfied.
  8. Consumer includes a data subject or consumer protected by Applicable Data Protection Law.
  9. Subprocessor means another processor engaged by Database to Process Customer Personal Data.
  10. Security Incident means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Personal Data. It excludes an unsuccessful attempt that does not result in such destruction, loss, alteration, disclosure, or access.
  11. Services means the Database-hosted services Customer uses under the Agreement.

2. Roles and scope

  1. Customer role. For Customer Personal Data, Customer determines the appointment, service, staffing, scheduling, customer-relationship, communication, recordkeeping, and other business purposes for which the data is collected and used. Customer is the Controller.
  2. Database role. Database Processes Customer Personal Data on Customer's documented instructions to provide the Services. For that Processing, Database is Customer's Processor and, where the CCPA applies, Customer's service provider or contractor as determined by the actual disclosure path and satisfaction of the corresponding statutory and contractual requirements.
  3. Consumers. An individual who submits Booking Data is a Consumer of Customer and is not a party to these DPT merely by making a booking.
  4. Separate Database purposes. These DPT do not govern Personal Data for which Database lawfully determines a separate purpose and means, such as Customer-account administration, billing, direct contractual communications, or compliance with Database's own legal obligations. Database must identify any such separate Processing in an applicable privacy notice and may not reclassify Customer Personal Data merely by contract label.
  5. Context controls. The parties acknowledge that roles are determined by actual conduct and Applicable Data Protection Law, not solely by this section. Database will not determine an independent advertising, sale, sharing, or unrelated profiling purpose for Booking Data under these DPT.

3. Customer instructions

  1. Customer instructs Database to Process Customer Personal Data only as necessary to provide, operate, secure, protect, administer, and support the Customer-requested Services described in the Agreement and Annex 1; implement Customer's configuration and lawful requests; send Customer-authorized transactional communications; prevent abuse and security incidents; and satisfy unavoidable legal obligations consistent with the role allocation in section 2.
  2. The Agreement, Customer's use and configuration of the Services, and Customer's written support requests constitute documented instructions. Additional instructions must be consistent with the Agreement and Applicable Data Protection Law.
  3. Database will Process Customer Personal Data only on documented instructions, including for an international transfer, unless Applicable Data Protection Law requires otherwise. For Processing governed by EU GDPR or UK Data Protection Law, that exception is limited to applicable Union or Member State law or UK domestic law. Database will notify Customer before the legally required Processing unless that law prohibits notice on important grounds of public interest.
  4. Database will immediately inform Customer if, in Database's opinion, an instruction infringes applicable EU, Member State, or UK data-protection law and will promptly inform Customer of an instruction that it reasonably believes infringes another Applicable Data Protection Law. Database may suspend the affected instruction while the parties resolve the issue.
  5. Customer is responsible for the lawfulness, accuracy, transparency, and sufficiency of its instructions and for providing any notice or obtaining any authorization required from Consumers.

4. Processing restrictions

For Customer Personal Data, Database will:

  1. Process only for the limited and specified purposes in these DPT and the Agreement;
  2. not sell or share Customer Personal Data, as those terms are defined by the CCPA;
  3. not retain, use, or disclose Customer Personal Data outside the direct business relationship with Customer or for a commercial purpose other than the specified business purposes, except as permitted by Applicable Data Protection Law;
  4. not combine Customer Personal Data with Personal Data received from another person or collected from Database's own interaction with a Consumer except where Applicable Data Protection Law expressly permits the combination for a specified business purpose;
  5. not use Booking Data for cross-context behavioral advertising, targeted advertising, data brokerage, an unrelated profile of a Consumer, training a general-purpose artificial intelligence model, Database's direct marketing to Customer's booking customer, or another undisclosed independent commercial purpose. Any separately authorized Processing for one of those purposes is outside these DPT and requires a separate lawful role allocation, agreement, and notice before it begins;
  6. comply with applicable obligations and provide the same level of privacy protection required of Customer for the Processing delegated to Database;
  7. notify Customer if Database determines it can no longer meet an applicable obligation; and
  8. permit Customer to take reasonable and appropriate steps to stop and remediate unauthorized use of Customer Personal Data.

5. Confidentiality and personnel

  1. Database will limit access to Customer Personal Data to personnel and contractors who need access for the permitted Processing.
  2. Database will ensure that persons authorized to Process Customer Personal Data are bound by an appropriate duty of confidentiality and receive relevant privacy and security instructions.
  3. Database remains responsible for its personnel's compliance with these DPT.

6. Security

  1. Database will implement and maintain appropriate technical and organizational measures designed to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, and unauthorized access, taking into account the state of the art, implementation costs, the nature and scope of Processing, and the risks to Consumers.
  2. The baseline measures in Annex 2 form part of these DPT. Database may update them without materially reducing the overall protection of Customer Personal Data.
  3. Customer is responsible for configuring and using the Services securely, protecting its account credentials, limiting its users' access, and promptly notifying Database of suspected compromise.

7. Consumer requests and compliance assistance

Taking into account the nature of the Processing, Database will assist Customer through appropriate technical and organizational measures, insofar as possible, with requests to access, know, correct, delete, restrict, object, opt out, or obtain a portable copy of Customer Personal Data. Taking into account the nature of the Processing and information available to Database, Database will also assist Customer with:

  1. security, breach-notification, data-protection impact or risk-assessment, and prior-consultation obligations, including EU/UK GDPR Articles 32 through 36 where applicable;
  2. information necessary to demonstrate compliance with applicable Processor obligations; and
  3. routing a request Database receives directly from a Consumer to Customer, unless law requires Database to respond directly.

Unless prohibited by law, Database will not independently decide the merits of a request concerning Customer Personal Data. Customer remains responsible for authenticating the requester, deciding the response, and giving Database a lawful instruction. Requests and instructions may be sent to info@mydatabaseapp.com or another support channel stated in the Agreement.

Where the CCPA applies, Database will enable Customer to comply with Consumer requests by acting on Customer's lawful documented instructions. If Database receives a request directly concerning Customer Personal Data, Database will either act in accordance with Customer's documented instructions or inform the Consumer that Database cannot act on the request because it was submitted to a service provider or contractor, and will provide or direct the Consumer to Customer's request method when Customer has supplied it.

8. Security incidents

  1. Database will notify Customer without undue delay after becoming aware of a Security Incident affecting Customer Personal Data and will not delay initial notice until an investigation, risk assessment, or complete set of facts is final.
  2. As information becomes reasonably available, including in phases, the notice will describe the nature of the incident, affected data and Consumers, likely consequences, mitigation taken or proposed, and a contact for follow-up.
  3. Database will take reasonable steps to contain, investigate, mitigate, and remediate the Security Incident and will reasonably cooperate with Customer's legally required notifications.
  4. Notification is not an admission of fault or liability. Customer is responsible for determining whether it must notify Consumers, regulators, or others, except where law assigns that duty to Database.

9. Subprocessors

  1. Customer gives Database general written authorization to engage the Subprocessors listed in Annex 3 and replacement or additional Subprocessors under this section.
  2. Before a Subprocessor Processes Customer Personal Data, Database will impose by written contract the same data-protection obligations imposed on Database under these DPT for the delegated Processing.
  3. Database remains fully liable to Customer for each Subprocessor's performance of those delegated obligations where EU GDPR or UK Data Protection Law applies and remains responsible to the extent required by any other Applicable Data Protection Law.
  4. Where Customer has given general authorization and Applicable Data Protection Law requires notice of changes, Database will provide reasonable written advance notice of an intended addition or replacement of a Subprocessor that will Process Customer Personal Data, with enough information and opportunity for Customer to object on reasonable data-protection grounds before that Processing begins. No fixed notice period applies unless the Agreement or Applicable Data Protection Law requires one. The parties will work in good faith on a commercially reasonable resolution. If no resolution is available, Customer may stop using the affected feature or terminate it as provided by the Agreement.
  5. Annex 3 identifies technical recipients from the established service architecture. A recipient that Processes Customer Personal Data on Database's behalf is a Subprocessor based on its actual function; absent or insufficient downstream terms make the engagement noncompliant rather than changing that functional status. Inclusion does not represent that a vendor has made a contractual commitment beyond the vendor agreement actually in force. Database must verify required written downstream terms before engaging the recipient for covered Processing or representing that CCPA service-provider or contractor conditions are satisfied.

10. International transfers

  1. Database will not transfer Customer Personal Data in violation of Applicable Data Protection Law.
  2. If EU GDPR restricted-transfer rules apply, the parties will use the lawful mechanism available for the actual transfer: an applicable adequacy decision; an Article 46 safeguard, including the then-current European Commission standard contractual clauses where those clauses are within scope; or an available Article 49 derogation. The parties will complete all mechanism-specific modules, annexes, assessments, and supplementary measures before the restricted transfer where required.
  3. If UK restricted-transfer rules apply, the parties will use an applicable adequacy regulation, the then-current UK International Data Transfer Addendum to eligible EU standard contractual clauses, the UK International Data Transfer Agreement, or another lawful UK transfer mechanism. The exporter must document the current UK data protection test and reasonably and proportionately conclude that protection after transfer is not materially lower than under UK Data Protection Law.
  4. Database will provide information necessary for the applicable EU transfer assessment or UK data protection test, reassess relevant changes, and implement effective supplementary measures where needed. If the applicable protection standard cannot be met, the transfer must not begin or must be suspended.
  5. These DPT do not claim that Database or a Subprocessor participates in an adequacy framework or that a particular transfer mechanism applies unless controlled records verify the relevant legal entity, destination, exporter/importer roles, mechanism eligibility, completed instrument, and scope.

11. Return, deletion, and retention

  1. While acting as Processor, Database will retain Customer Personal Data only as necessary to provide and protect the covered Services, carry out Customer's documented instructions, and satisfy an applicable lawful retention requirement. Retention and deletion timing may differ by system and provider lifecycle as described in Annex 4.
  2. Customer may send an authenticated export, return, or deletion instruction through the support channel in section 7. Database will take the action required by Applicable Data Protection Law using the technical capabilities then available for the affected data and the documented ordinary deletion cycles in Annex 4. This paragraph does not promise immediate or universal physical erasure.
  3. Where Applicable Data Protection Law requires return or deletion at the end of the covered Services, Database will, at Customer's choice, return or delete Customer Personal Data and delete existing copies, except to the extent applicable law requires or permits continued storage. Database will not undertake Processing for which a mandatory return or deletion obligation cannot be lawfully met.
  4. Customer Personal Data remaining in a job queue, log, backup, or provider-managed system will be removed from ordinary use and deleted, overwritten, or rendered inaccessible under the applicable documented lifecycle where required by Applicable Data Protection Law and technically feasible. Provider-managed copies remain subject to the provider lifecycle and the downstream terms in force.
  5. If a backup containing data subject to a continuing deletion instruction is restored, Database will keep the data subject to that instruction before ordinary reuse where required by Applicable Data Protection Law and technically feasible.
  6. If applicable law requires or permits retention, Database will, where legally and technically feasible, isolate the retained data from unrelated Processing, use it only for the permitted purpose, and delete it when that purpose ends. A legal hold does not authorize unrelated use.
  7. Any retention for Database's independent legal-claims, security, fraud-prevention, or other independent purpose is outside the Processor role, must be separately lawful and disclosed under section 2, and does not expand the Processing permitted by these DPT.
  8. A public notice must not promise a shorter fixed period or broader deletion capability unless Database has separately implemented and documented it.

12. Audit and demonstration of compliance

  1. On reasonable written request, Database will make available the information necessary to demonstrate compliance with mandatory Processor obligations applicable to the covered Processing. Database may satisfy the request first through suitable existing evidence, such as security summaries, relevant test records, responses to a proportionate questionnaire, or any current audit report or certification that Database actually maintains. Nothing in these DPT promises a certification or recurring independent audit that Database does not maintain.
  2. Customer may conduct an audit or inspection only to the extent Applicable Data Protection Law gives Customer that right and existing evidence is insufficient to satisfy it. The audit must be limited to the covered Processing, coordinated in advance, conducted by Customer or an independent auditor bound by confidentiality, avoid unreasonable disruption, and protect other customers and security information where those conditions do not prevent or materially delay a mandatory audit. No more frequent or broader contractual audit right is created than Applicable Data Protection Law requires.
  3. To the extent permitted by Applicable Data Protection Law and not unreasonably burdensome to a mandatory audit right, Customer bears its audit costs unless the audit establishes material noncompliance by Database.
  4. Database will maintain records of Processor activities and cooperate with a competent supervisory authority to the extent required by Applicable Data Protection Law.
  5. Database will contribute to audits and inspections by a competent supervisory authority as required by Applicable Data Protection Law.
  6. Where the CCPA applies, Customer may take reasonable and appropriate steps to help ensure that Database uses Customer Personal Data consistently with Customer's obligations, including the legally permitted monitoring measures stated in the applicable regulations.

13. Sensitive data and booking notes

  1. The standard booking workflow is not designed for health information, precise geolocation, government identifiers, financial-account credentials, biometric data, information about a known child, or another specially regulated category unless the Agreement expressly supports that data and the parties document the required controls.
  2. Customer will not instruct Consumers to submit specially regulated data through booking notes or other general-purpose fields without a written amendment addressing the data, legal basis, security, access, retention, and deletion requirements.
  3. If Database becomes aware that unsupported sensitive data has been submitted, Database will reasonably cooperate with Customer to restrict, return, or delete it under Customer's lawful instruction.

14. Customer obligations

Customer will:

  1. comply with Applicable Data Protection Law as Controller;
  2. provide all required notices at or before collection and maintain a lawful basis or authorization for the Processing;
  3. configure data collection to be adequate, relevant, and reasonably necessary for Customer's stated purposes;
  4. give Database only lawful instructions and respond to Consumer requests;
  5. identify retention requirements and issue timely return or deletion instructions; and
  6. ensure that its users and downstream recipients protect Customer Personal Data.

15. CCPA-specific terms

To the extent the CCPA applies:

  1. the limited and specified purposes in these DPT constitute the business purposes and services for which Customer discloses Personal Information to Database;
  2. Database acknowledges and certifies that it understands the restrictions in these DPT and will comply with applicable CCPA obligations;
  3. Database will provide the same level of privacy protection required by the CCPA for the delegated Processing;
  4. Customer has the right to take reasonable and appropriate steps to help ensure compliant use;
  5. Database will notify Customer if it determines it can no longer meet its CCPA obligations; and
  6. Customer may, upon notice, take reasonable and appropriate steps to stop and remediate unauthorized use of Personal Information.

Nothing in these DPT permits a sale, sharing, cross-context behavioral advertising, or a use outside the direct business relationship that the CCPA prohibits for a service provider or contractor.

16. Florida-specific terms

To the extent the FDBR applies, these DPT state the Processing instructions, nature and purpose, duration, types of Personal Data, categories of Consumers, and the parties' rights and obligations. Database will ensure confidentiality, assist Customer as required, make compliance information available, permit required audits, delete or return Personal Data at Customer's direction unless law requires retention, and bind each relevant subcontractor by written agreement to equivalent duties. The parties' actual conduct determines their statutory roles.

17. EU and UK terms

The Article 28 terms in these DPT apply whenever Customer is required by EU GDPR or UK Data Protection Law to bind Database as its Processor, independently of whether Database is itself directly within that law's territorial scope. The subject matter, duration, nature, purpose, data types, Consumer categories, and Controller rights are set out in these DPT and Annex 1. Database will comply with the applicable Processor duties, including documented instructions, confidentiality, security, Subprocessor controls, assistance with Consumer rights and Controller compliance, deletion or return, compliance information, audits, and notice of an unlawful instruction.

18. Liability, warranties, termination, and general terms

  1. The Agreement's AS-IS, AS-AVAILABLE, warranty-disclaimer, liability, indemnity, governing-law, dispute-resolution, and termination provisions apply to these DPT to the maximum extent permitted by law. They do not exclude a duty or remedy that Applicable Data Protection Law makes non-waivable.
  2. The security and confidentiality obligations in these DPT are risk-based obligations, not warranties of absolute security, absolute confidentiality, zero incidents, uninterrupted or error-free service, absolute availability, or immediate deletion from every system or provider copy.
  3. A material breach of these DPT is a material breach of the Agreement. If a breach cannot be cured, the nonbreaching party may terminate the affected Processing or Agreement as permitted by the Agreement and law.
  4. Obligations that by their nature apply after termination—including confidentiality, applicable deletion, audit cooperation, and liability—survive for as long as Database retains Customer Personal Data.
  5. If a competent authority invalidates part of these DPT, the remainder continues to apply, and the parties will replace the invalid term with a lawful term that most closely preserves its purpose.
  6. An amendment must be in writing or made through an update mechanism permitted by the Agreement and Applicable Data Protection Law. Database will not materially reduce mandatory data-protection rights through an update.

19. Adoption and Customer cohorts

  1. New Customers. A new Customer becomes bound when it affirmatively accepts the then-current Agreement at signup or another contracting event that conspicuously incorporates or links these DPT. The acceptance record must identify the Agreement/DPT version or preserve an equivalent durable version reference.
  2. Existing Customers with an enforceable update route. An existing Customer whose accepted Agreement contains an enforceable update and continued-use mechanism may become bound through one direct, conspicuous notice that identifies these DPT as a material contractual update, links the exact version, states the prospective effective date, and explains that continued use after that date constitutes acceptance. Database must retain the governing Agreement, notice, delivery record, effective date, and a post-effective-date continued-use event. Re-acceptance at every login is not required.
  3. Other existing Customers. If Database cannot establish that paragraph 2 is legally and contractually sufficient for a Customer cohort—including where the accepted Agreement or its update authority cannot be evidenced—Database must obtain one affirmative re-acceptance or signed amendment for this material update before representing that cohort as bound. This is a one-time adoption event, not repetitive login consent.
  4. An end customer making an appointment through a Customer's booking link is not a DPT party and is not asked to accept these DPT merely to make a booking.

Annex 1 — Processing details

Item Details
Subject matter Hosting and operating Customer's public appointment-booking, scheduling, client-record, and related transactional-notification workflows
Duration The term of the covered Services plus the bounded return, deletion, backup-cycle, and legally required retention periods described in section 11; any independent legal-claims retention is outside the Processor role
Nature and purposes Collecting, validating, organizing, storing, retrieving, displaying, updating, transmitting, supporting, securing, troubleshooting, preventing abuse of, and deleting or returning Booking Data to provide Customer's requested Services
Consumers Customer's prospective and current appointment clients; Customer personnel represented in scheduling records; any person whose Personal Data Customer lawfully submits in the covered workflow
Personal Data Name; email; optional telephone number; appointment date/time and duration; selected business, store, staff member, and service; locale; customer notes or gift-card code where used; confirmation and appointment identifiers; pricing snapshots; transactional-message content and delivery metadata; tenant-scoped client history; security and request metadata necessary to protect the workflow
Sensitive data Not intended for standard use. Any specially regulated data requires the written controls in section 13
Frequency Continuous or event-driven according to Customer and Consumer use of the Services
Controller rights All rights and obligations stated in the Agreement and these DPT, including instructions, access to compliance information, return/deletion choices, audit, Subprocessor notice/objection, and Security Incident cooperation

Annex 2 — Baseline security measures

Database will maintain reasonable and appropriate measures proportionate to the covered Processing and its risks. The current baseline is designed to include:

  1. tenant-scoped authorization and access controls;
  2. least-privilege access for personnel and service credentials;
  3. transport encryption for public and provider communications;
  4. validation, rate limiting, abuse prevention, and fail-closed handling at public boundaries;
  5. data minimization for operational logs and prevention of plaintext booking/customer PII in the scoped operational logging paths;
  6. controlled change and dependency management with security-focused testing;
  7. data-integrity, recovery, and continuity measures supported by the Services' actual configuration and provider capabilities;
  8. security-event monitoring, triage, containment, remediation, and legally required notification;
  9. review of a Subprocessor's security and written terms before covered Processing; and
  10. proportionate review of the effectiveness of maintained measures.

These measures reduce risk; they do not guarantee that every incident, interruption, error, loss, or unauthorized act can be prevented.

Annex 3 — Current technical recipients and Subprocessor schedule

The following schedule identifies the launch architecture supported by repository evidence and current official vendor publications. A published standard entity or DPA is not represented as an account-specific custom agreement. Database must update this schedule before enabling a materially different recipient, location, or transfer path for Customer Personal Data.

Service Launch status and function Customer Personal Data Published provider / terms Processing and storage location Transfer status
Supabase Active core hosted database, authentication, database operations, and provider-managed backup infrastructure Booking, appointment, client, notes, locale, confirmation, audit, account, and related tenant-scoped records Supabase Pte. Ltd.; standard Data Processing Addendum, Version 1 (August 1, 2026), at https://supabase.com/legal/customer-resources/data-processing-addendum The exact Database project region is not established in the repository. Supabase states that primary project data is stored and primarily processed in the selected project region, with other processing possible where Supabase or its subprocessors operate No current EU/UK restricted-transfer branch is established by the launch facts. Before such a branch begins, Database must verify the actual region and parties and complete any required SCC, UK Addendum, assessment, and supplementary measures under the standard DPA or other governing terms
Render Active core application hosting and operational infrastructure Request data processed in application memory; minimized operational metadata; any incident/error data reaching the hosting layer Render Services, Inc.; standard Data Processing Addendum at https://render.com/dpa Oregon, United States is the repository-configured service region. Exact account, log, support, and backup locations remain subject to Render's service configuration and provider lifecycle No current EU/UK restricted-transfer branch is established by the launch facts. Applicable transfer terms and assessments must be completed before covered restricted data is introduced
Resend Active for configured transactional email delivery Recipient email address, generated appointment/message content, and delivery metadata Plus Five Five, Inc. d/b/a Resend; standard Data Processing Addendum updated August 27, 2026, at https://resend.com/legal/dpa Resend publishes United States storage and primary processing. A selected sending region controls routing, not storage; the Database account's sending region is not established in the repository No current EU/UK restricted-transfer branch is established by the launch facts. Resend publishes EU SCC, UK, Swiss, and Data Privacy Framework mechanisms; the applicable parties and assessment must be verified before a covered restricted transfer
Sentry Not used at launch for covered Booking Data Processing. Activation requires a separate enablement decision and configuration update Not applicable at launch Not applicable at launch Not applicable at launch Not applicable at launch

Database's use of each active provider is governed by the applicable account agreement and provider terms then in force. The responsible owner must retain the account-level agreement or acceptance record and resolve any conflict between it and the published standard terms before relying on a provider for a new legally restricted processing context. Sentry may not be added to the active schedule merely because an SDK or optional environment field exists.

Annex 4 — Current return, deletion, and retention lifecycle

The current service does not promise immediate or universal deletion. The following lifecycle is the truthful operational boundary at this version:

Data location Current lifecycle
Active appointment and client records No general automated hard-deletion cycle is represented. An authenticated return/deletion instruction is handled through the support process and may require a bounded manual or technical action. Database must not undertake Processing for which Applicable Data Protection Law requires a deletion capability that cannot be lawfully performed.
Soft-deleted appointment records A soft-delete flag removes the record from ordinary active use but is not represented as irreversible erasure. No fixed automatic purge period is promised.
Background job queues The documented application cleanup cycle is 30 days. A valid instruction may require earlier handling where technically feasible and legally required.
Application audit or delivery records Retention varies by record. Scoped operational logging is designed not to emit plaintext booking/customer name, email, telephone, or notes, but no universal application-log deletion period is promised.
Platform logs Provider lifecycle applies. Database will use available configuration and support processes to minimize, restrict, or delete covered Personal Data where required and supported.
Provider-held operational copies Provider lifecycle and the downstream terms in force apply. Resend currently publishes 30-day email/log retention for Free, Pro, and Scale plans, adjustable Enterprise retention, account-data deletion within 90 days after termination, and a seven-day backup lifecycle; Database's account class is not represented here.
Backups and point-in-time recovery copies Provider lifecycle applies. Copies are not promised to be erased immediately. Where required, they must remain outside ordinary use until overwritten or deleted under the applicable cycle.
Legal holds or other lawful retention No standing legal-hold capability is represented. If lawful retention is invoked, the affected data must be restricted to the permitted purpose and remain subject to deletion when that purpose ends.
Restored backups No universal automated re-deletion capability is represented. Before Processing for which re-deletion is mandatory, Database must establish a process that reapplies a continuing valid deletion instruction before ordinary reuse.

Database will review this schedule when a material Customer cohort, processing purpose, recipient, transfer path, security measure, or deletion capability changes. Account-level vendor records and Customer adoption evidence are retained as controlled business records rather than published secrets.