Data Processing Addendum

1. Purpose, roles and scope

Customer directs Provider to process personal data to deliver the restaurant operations Services, including user identity, orders, customer contact details, workforce information, device events, receipts, and support records as applicable. Customer is ordinarily the controller/business for restaurant-controlled personal data; Provider acts as processor/service provider for that data. Provider may independently control separate business-contact, marketing-intake/lead and optional consent records, subscription-billing, product security and legal-compliance records; such independent website lead uses must be described in the published Privacy Policy and must not be silently treated as restaurant-instructed processing. Actual roles may differ for particular Stripe/identity operations and must be assessed based on law and data flows. This DPA governs processing only to the extent the applicable privacy laws require or permit the assigned roles.

2. Customer instructions

Provider will process Customer Personal Data only to provide Services, follow documented configuration and support instructions, protect Services, comply with law, and meet the MSA. Provider will notify Customer when it believes an instruction violates applicable law, unless prohibited. Customer warrants lawful notice, authority, legal basis/consent where needed, and staff/guest data accuracy; Customer may not instruct unlawful surveillance or misuse of employee identifiers.

3. Confidentiality and access

Provider restricts access to personnel and subprocessors with appropriate need and confidentiality obligations. Customer controls its authorized administrators, staff roles, POS PINs and device enrollment, and must promptly remove departing workers.

4. Security measures

Provider will implement reasonable measures taking account of sensitivity and risk, including appropriate account access control, secure transmission, credential management, logging, backups and incident response, as documented in its operative security program.

Local devices and networks are Customer's responsibility except for controls built into Provider's application.

5. Subprocessors

Customer generally authorizes use of vetted subprocessors necessary to perform Services, subject to data-protection obligations appropriate to their access.

Subprocessors used to perform the Services include Microsoft Azure (cloud hosting, storage and key management, and transactional email through Azure Communication Services), Twilio (verification messaging), and, where enabled, third-party identity providers (Google and Microsoft sign-in) and payment services.

Stripe may act independently under its own account/payment terms, so its data-protection role is not uniformly "subprocessor." Provider should maintain and make available a current subprocessor list and provide reasonable notice of material replacements when legally required. Any objection will be considered in good faith with reasonable alternative/termination discussions; no obligation to provide technically impossible alternatives is implied.

6. Security incidents

Provider will notify Customer without undue delay after determining that a confirmed breach of security of Customer Personal Data occurred, and will provide known categories, affected scope, remedial steps and continuing updates where reasonably available. Notification timing and content must comply with the laws applicable to the incident; this contract does not shift mandatory regulator/individual notification duties away from the legally responsible party. Both parties will cooperate in a timely manner.

7. Data subject requests and regulators

Provider will reasonably assist Customer with requests for access, correction, deletion, portability, objections or restrictions as technically possible and legally required, after identity verification and subject to lawful retention. Direct requests concerning restaurant-controlled records may be forwarded to Customer. Each party remains responsible for its own direct legal obligations.

8. Return, export and deletion

Upon termination, Provider will follow its written retention and deletion schedule, provide an export of Customer Data as described in this Section when requested and legally permissible, and retain only data needed for lawful records, defense of legal claims or technically unavoidable short-lived backups.

Self-service export of Customer Data is not currently available in the Services, and Provider does not promise an automated export. During the subscription or after termination, Customer's authorized owner may request an export by email to info@dinestack.app sent from the account owner's email address. After verifying the requester's identity and authority, Provider will provide an export of Customer Data in a commonly used, machine-readable format within a reasonable time and in any case within any period required by applicable law, subject to lawful retention and security requirements.

No fixed export or deletion deadline is otherwise promised in this DPA.

Customer must independently remove data from its former employees' or retired devices.

9. Transfers and jurisdiction

Provider may use regional or cross-border infrastructure only in accordance with applicable law, contract, customer communications and available transfer mechanisms.

This DPA by itself is not a substitute for mandatory standard clauses or specialized provincial notices.

10. Assurance and audit

On reasonable written request and subject to confidentiality, Provider will provide available security documentation needed to demonstrate compliance with relevant DPA obligations. Any on-site audit is subject to reasonable scope, confidentiality, protection of other customers' data and prior scheduling; third-party certification or security reports may be provided instead where appropriate and allowed by law. Customer may not conduct intrusive security testing without express prior written authorization.

11. Conflict and term

The DPA prevails over inconsistent MSA provisions solely for required personal-data processing obligations and remains in effect for so long as Provider processes Customer Personal Data. Statutory rights may not be waived by contract.

Schedule A — Processing description

A multi-restaurant identity must not give a Customer access to another legal customer's data without documented authorization.

Subject: Restaurant workforce, diner and operational data handled in enabled Services.

Purpose: Restaurant account, POS, order, menu, staff/permission, device, customer receipt, delivery, support and authorized payment-reconciliation functions.

Duration: Subscription term plus retention legally or operationally justified under published schedules.

Categories: Restaurant owners, staff, drivers, guests, business contacts and authorized third-party contacts.

Data: Contact information, login/account markers, employment/role fields where enabled, restaurant order and receipt data, device and audit logs, and limited payment-processor references/statuses; sensitive workforce identifiers only if activated and lawfully required.

Device location: Not collected or stored by Provider. Where Tap to Pay is enabled on a business phone approved by Customer's owner, the approximate location that the payment provider's software (Stripe Terminal) requires is used by that software on the device and is not sent to Provider.

Special categories: Not an intended collection category; should not be entered unless expressly authorized and a separate legal/security assessment is completed.