SureAppoint Data Retention Policy

FOUNDER-AUTHORIZED INTERIM POLICY

Published for current use by founder authorization on August 4, 2026. This interim policy remains subject to future review by qualified privacy, healthcare, and commercial counsel. No retention duration in this document is final or approved for Production operations.

Version: v1.0-2026-08-04

Effective date: August 4, 2026

Policy owner: Founder, unless explicitly delegated

1. Purpose

This policy defines the categories and purposes of information SureAppoint may retain. It is designed to preserve the evidence necessary to administer Appointment Guarantees while avoiding a duplicate patient, clinical, or appointment system of record.

The Practice remains authoritative for attendance, scheduling history, clinical information, patient demographics, and the complete patient record. SureAppoint retains only the information needed for guarantee delivery, acceptance, payment facilitation, Practice-authorized financial actions, security, disputes, accounting, and compliance.

SureAppoint retains information only for as long as it serves an operational, legal, financial, security, or evidentiary purpose. Information that no longer serves those purposes is deleted, de-identified, or retained only where required by law or contractual obligations. SureAppoint does not promise one fixed retention period for every category.

Every duration below is intentionally unresolved and must be approved during legal review before this policy becomes operational.

The participant terms have the meanings stated in the Terms of Service:

• Patient Subject: The person or people associated with the Practice-defined Appointment Unit.
• Guarantee Acceptor: The person who accepts the Practice Policy and Accepted Maximum.
• Payment Authorizer: The person who authorizes possible future use of the Stripe-hosted payment method.

The roles may be filled by the same person or different people.

Document precedence

TODO (Legal Review): Approve this intended order of precedence before any document is published or signed:

1. A signed amendment or order form, but only when it expressly identifies the provision it overrides.
2. An applicable Business Associate Agreement or Data Processing Addendum, but only for its specific privacy, security, or data-processing subject matter.
3. The Commercial Agreement.
4. The Terms of Service.
5. The Acceptable Use Policy.
6. The Privacy Policy and Data Retention Policy, each for its specific subject matter.

No document may retroactively alter an accepted Appointment Guarantee, Policy Snapshot, Maximum Fee Snapshot, Payment Authorization, Practice Resolution, or historical evidence. If documents at the same level conflict, the more specific approved term controls only for its subject matter.

2. Retention roles

Retention owner identifies the role responsible for approving and applying the category's retention rule. It does not determine legal ownership of the underlying information.

• The founder owns routine retention and disposition unless that responsibility is explicitly delegated.
• The technical or security owner implements approved deletion, anonymization, backup, and legal-hold controls.
• The finance or payment-reconciliation owner preserves required financial and dispute evidence.
• The Practice remains responsible for records maintained in its own scheduler, EMR, Stripe account, and business systems.
• Counsel approves legal, regulatory, contractual, and litigation-hold requirements.

3. Practice account and office information

Examples: Practice name, office name, phone, email, provider name, timezone, support contact, account email, account status, settings, and legal or billing contact information supplied during onboarding.

Purpose: Authenticate the Practice, identify the sender to participants, configure the Services, provide support, and preserve account administration evidence.

Retention owner: Founder or designated privacy owner, with the technical owner.

Duration: To be finalized during legal review.

Disposition: Delete or anonymize information that is no longer needed after account closure, subject to unresolved payments, disputes, security events, contractual duties, and legal holds. Preserve only the minimum identity evidence required to interpret retained guarantee and financial records.

4. Published policy versions and policy provenance

Examples: Policy family ID, immutable version ID, version number, published timestamp, publishing actor reference, content hash, title, and published wording.

Purpose: Prove which Practice Policy existed, who published it, and which version governed an Appointment Guarantee.

Retention owner: Founder or designated data-governance owner, with the technical owner.

Duration: To be finalized during legal review.

Disposition: Retain immutable versions while required to interpret active or retained guarantees and related disputes. When legally permitted and no longer required, delete or de-identify internal actor information that is not necessary to preserve policy provenance. Never rewrite a historical published version.

5. Policy snapshots

Examples: The policy name and exact terms displayed for a specific Appointment Guarantee.

Purpose: Prove what the Guarantee Acceptor was shown and accepted even if the Practice later publishes a replacement policy version.

Retention owner: Founder or designated data-governance owner, with counsel.

Duration: To be finalized during legal review.

Disposition: Retain with the guarantee evidence for the approved evidentiary period. Delete only under an approved disposition rule that accounts for disputes, payment history, and legal holds. Do not update the snapshot to match a later policy.

6. Fee snapshots

Examples: The immutable maximum fee, fee-schedule name, and applicable commercial fee version recorded for the guarantee or transaction.

Purpose: Prove the maximum the Guarantee Acceptor accepted, prevent retroactive increases, and reconcile Practice-authorized charges and SureAppoint fees.

Retention owner: Finance or payment-reconciliation owner, with the data-governance owner.

Duration: To be finalized during legal review.

Disposition: Retain while required for guarantee evidence, accounting, refunds, disputes, and legal obligations. Delete or de-identify only under an approved schedule. Never replace a historical fee snapshot with a later fee.

7. Appointment identifiers

Examples: Patient Subject name and the limited Appointment Unit date, time, office, and provider information required to identify an Appointment Guarantee.

Purpose: Allow the Patient Subject, Guarantee Acceptor, Payment Authorizer, and Practice to understand which Appointment Unit the guarantee concerns.

Retention owner: Founder or designated privacy owner, with the Practice responsible for the complete source appointment record.

Duration: To be finalized during legal review.

Disposition: Retain the minimum identifying context required to interpret the guarantee and payment evidence. Delete or anonymize unnecessary identifiers when the approved evidentiary, dispute, and legal periods end. Do not expand this category into general scheduling history.

8. Participant contact information

Examples: Mobile number and email address used for secure-link delivery and guarantee identification.

Purpose: Deliver or redeliver the secure link, identify the intended recipient, support a limited correction, and investigate delivery or security issues.

Retention owner: Founder or designated privacy owner, with the technical owner.

Duration: To be finalized during legal review.

Disposition: Delete, mask, or irreversibly anonymize contact details when they are no longer required for delivery, guarantee evidence, an active dispute, security review, or legal obligation. Do not reuse them for unrelated marketing or create a longitudinal patient contact record.

9. Acceptance and payment-method status

Examples: Guarantee Acceptor acceptance timestamp, accepted policy version, Accepted Maximum, Payment Authorizer authorization timestamp, revocation timestamp, Payment Method Secured status, Stripe SetupIntent or PaymentMethod reference, replacement relationship, and Appointment Guaranteed timestamp.

Purpose: Prove Guarantee Acceptor acceptance and Payment Authorizer authorization, distinguish acceptance from payment setup, prevent future use after revocation, and support a later authorized Practice decision.

Retention owner: Data-governance owner and payment-reconciliation owner.

Duration: To be finalized during legal review.

Disposition: Retain the minimum evidence needed for disputes, accounting, and compliance. Revocation never rewrites the original acceptance, authorization, delivery, or financial history and does not automatically reverse a completed financial action. A replacement guarantee requires a new secure link, fresh acceptance, and a new Payment Authorization. Delete or de-identify provider references when no longer required and legally permitted. Do not store full card data.

10. Delivery events

Examples: Created, copied, submitted, delivered, failed, expired, and viewed events; provider message reference; timestamps; and safe failure details.

Purpose: Record how the secure link was handled without falsely treating a copied or submitted link as delivered.

Retention owner: Operations or support owner, with the technical owner.

Duration: To be finalized during legal review.

Disposition: Retain events needed for delivery support, audit accuracy, and disputes. Delete or de-identify provider metadata and technical details that no longer serve an approved purpose.

11. Audit events

Examples: Material account, policy, guarantee, payment, refund, dispute, activation, and administrative events.

Purpose: Establish authority, sequence, tenant ownership, security context, and evidence for operational review and disputes.

Retention owner: Security and data-governance owners.

Duration: To be finalized during legal review.

Disposition: Preserve material audit evidence in an integrity-protecting form for the approved period. Remove or de-identify unnecessary actor or technical details when permitted. Do not use the audit trail as a duplicate clinical or appointment record.

12. Stripe payment, refund, and dispute records

Examples: Connected-account reference, PaymentIntent and Charge references, amounts, statuses, authorized Practice decision, refund state, application fee, dispute status, and reconciliation evidence.

Purpose: Facilitate and reconcile Practice-authorized payments, calculate SureAppoint fees, prevent duplicate action, respond to refunds or disputes, and meet accounting obligations.

Retention owner: Finance or payment-reconciliation owner, with the technical owner and counsel.

Duration: To be finalized during legal review.

Disposition: Retain the minimum transaction and reconciliation evidence required by approved accounting, payment, dispute, and legal rules. Delete or de-identify nonessential provider metadata when permitted. Full card numbers, bank credentials, and Stripe passwords must not be retained by SureAppoint.

13. Application and security logs

Examples: Sanitized application errors, authentication events, request metadata, security detections, deployment logs, and infrastructure logs.

Purpose: Maintain availability, diagnose failures, investigate security events, and demonstrate operational control.

Retention owner: Technical or security owner.

Duration: To be finalized during legal review.

Disposition: Rotate and delete logs under an approved schedule. Redact or avoid secrets, full secure links, guarantee tokens, client secrets, card data, and unnecessary patient information. Preserve relevant extracts only when needed for an active incident, dispute, or legal hold.

14. Webhook events and payloads

Examples: Stripe event identity, provider event type, processing status, reconciliation state, and the minimum provider data required to process the event.

Purpose: Verify provider events, prevent duplicate processing, reconcile payments and disputes, and investigate failures.

Retention owner: Payment-reconciliation and technical owners.

Duration: To be finalized during legal review.

Disposition: Retain durable event identity and reconciliation state as required. Do not retain raw webhook payloads indefinitely. Delete transient or duplicative payload data after the approved processing, troubleshooting, security, and dispute needs end.

15. Secure-link tokens

Examples: Hashed token lookup, encrypted recoverable token, creation, regeneration, expiration, and invalidation state.

Purpose: Resolve valid participant links, permit authenticated recovery or redelivery, invalidate replaced links, and investigate misuse.

Retention owner: Technical and security owners.

Duration: To be finalized during legal review.

Disposition: Expire or invalidate links according to product rules. Delete or cryptographically dispose of token material when it is no longer required for approved recovery, audit, or security purposes. Preserve non-secret event evidence separately when needed.

16. Support records

Examples: Support emails, issue summaries, troubleshooting timestamps, and sanitized provider references supplied for a case.

Purpose: Resolve customer issues, document operational actions, identify security or payment incidents, and improve documentation.

Retention owner: Founder or designated support owner.

Duration: To be finalized during legal review.

Disposition: Delete or de-identify resolved support records when no longer needed. Remove unnecessary patient information and never request or retain full card numbers, passwords, API keys, bank credentials, identity documents, or webhook secrets.

17. Backups and restore points

Examples: Managed database restore points, deployment backups, and configuration backups that may contain retained Production records.

Purpose: Recover from data loss, migration failure, corruption, or an operational incident.

Retention owner: Technical or infrastructure owner, with the security owner.

Duration: To be finalized during legal review.

Disposition: Expire backups under an approved rotation schedule and provider capabilities. Limit access, test restoration, and account for delayed deletion from backups in the final Privacy Policy and request procedures.

18. Founder-created test data

Examples: Synthetic practices, policies, participant names, contact details, Appointment Guarantees, and SureAppoint Sandbox references created for validation.

Purpose: Validate setup, migrations, browser behavior, and the production baseline before real-customer onboarding.

Retention owner: Founder and technical owner.

Duration: To be finalized during legal review.

Disposition: Clearly identify, segregate where practical, and delete or anonymize test data when its validation purpose ends. Never treat founder test data as customer history or use real patient or live payment information as a test fixture.

19. Legal holds and exceptions

Routine deletion or anonymization must pause for information subject to:

• An active payment dispute or refund reconciliation.
• A security investigation.
• A subpoena, court order, regulatory request, or litigation hold.
• An applicable accounting, tax, contractual, or legal preservation requirement.

Counsel must define who can issue and release a hold, how affected information is identified, and how disposition resumes afterward.

20. Approval required before implementation

Before this policy becomes operational:

• [ ] Counsel approves each duration and legal basis.
• [ ] The founder approves the business need for each retained category.
• [ ] The technical owner confirms that each approved disposition is feasible.
• [ ] The Privacy Policy and customer agreements use consistent language.
• [ ] Provider-specific retention and deletion behavior is documented.
• [ ] Backup deletion limitations are documented.
• [ ] Privacy-request procedures account for immutable evidence.
• [ ] Legal-hold procedures are approved.
• [ ] Founder test data has an approved disposition.