Data processing agreement

Processor: PLACEHOLDER, registered address/country PLACEHOLDER, contact PLACEHOLDER. Customer: the legal entity named in the accepted service order; its name, address and authorised privacy contact must be recorded there. Effective date: PLACEHOLDER.

Customer determines the purposes and means of handling its app users’ support data and acts as controller, or as a processor authorised by its controller to appoint us. We act as processor or subprocessor accordingly. Applicable data protection law includes the EU GDPR and UK GDPR where they apply. Controller, processor, personal data and personal data breach have their meanings under that law. Our independent account, security and billing activities are described in the Privacy Policy.

We will handle customer personal data only to deliver the agreed support service and follow the customer’s documented lawful instructions, including its authorised configuration and requests. This restriction includes transfers. If law requires other processing, we will inform the customer before it occurs unless the law prohibits that notice. We will promptly tell the customer if an instruction appears to infringe applicable data protection law.

The customer is responsible for its notices, lawful basis, data accuracy and authority to submit information, appoint processors and enable integrations. It will not instruct processing outside the agreed scope without a written amendment. We will not sell customer personal data or independently use support content for advertising or model training.

We will restrict access to people who need it for an authorised task and ensure they are bound by confidentiality duties. We will maintain technical and organisational safeguards appropriate to the nature and risks of the processing, and assess them as the service changes. The security schedule below distinguishes application controls from deployment measures requiring confirmation.

Customer controls its team access, app integration, end-user disclosures and the recipients of optional notifications. Credentials must be protected and unnecessary personal data excluded. These customer responsibilities do not remove our own obligations as processor.

Customer authorises only the providers and processing described in a completed, accepted subprocessor schedule. No blank provider entry is an authorisation. We will bind subprocessors to equivalent applicable data-protection obligations and remain responsible to the customer for their performance of those obligations.

For future additions or replacements under general authorisation, we will give at least 30 days’ written notice identifying the provider, purpose, location and relevant safeguards. Customer may object on reasonable data-protection grounds within that period. We will discuss a suitable alternative; if none can be agreed, customer may end the affected service before the new processing begins, with a proportional refund of unused prepaid fees for it.

Services the customer independently selects, such as a Telegram destination, may also act under their own terms. Their classification must follow the actual arrangement. Labelling a service a customer integration does not remove any processor obligations that apply to us.

Taking account of the processing and information available to us, we will provide appropriate assistance with access, rectification, erasure, restriction, portability and objections, and with security duties, breach notifications, impact assessments and prior consultation with supervisory authorities.

If we receive a request relating to customer-controlled data, we will notify or direct it to the customer and will not decide the response unless instructed or required by law. We will provide assistance in time for applicable deadlines and agree a secure method for any disclosure or return.

We will notify the customer without undue delay after becoming aware of a personal data breach affecting its data. The initial notice will include the facts then available and a contact for follow-up; missing details will be supplied in stages without undue further delay.

As available, we will describe the incident, affected data and people, likely consequences and measures taken or proposed to contain and remedy it. We will preserve relevant information and reasonably cooperate with the customer’s investigation and notification obligations. An initial report does not require a completed investigation. Customer determines notices to authorities and individuals unless law requires us to act directly.

Processing and access locations, importer identities, transfer mechanisms and any required assessments must be completed in the provider schedule before restricted transfers begin. We will follow documented customer instructions and applicable transfer rules.

Where standard contractual clauses or a UK transfer instrument are required, the parties will execute the applicable unmodified instrument with its options, parties and annexes completed, and any necessary supplementary measures. This draft does not itself execute those instruments or assert that an unspecified provider’s safeguards cover our transfers. Mandatory transfer terms prevail over conflicting service terms.

We will make available the information reasonably needed to demonstrate compliance with this DPA and allow and contribute to audits, including inspections, by the customer or an independent auditor it appoints. We will inform the customer if an instruction for an audit appears unlawful.

Audits should protect other customers’ data and system security, use confidentiality safeguards and ordinarily be coordinated on reasonable notice. These arrangements must not prevent urgent investigation, regulator access or the customer’s legal rights. Any exceptional assistance charges must be reasonable and agreed in advance, and may not obstruct required compliance.

Processing lasts for the service term and any agreed return/deletion period. At the customer’s choice, we will return or delete customer personal data when the relevant service ends, and remove remaining copies unless law requires retention. The method and timeframe for return and deletion, including backup expiry, are PLACEHOLDER and must be agreed before this DPA is effective.

Where law requires retention, we will identify the requirement where permitted, limit access and purposes, and delete when it no longer applies. Data waiting for backup expiry must be isolated from ordinary use and deleted on the agreed schedule; restored backups must have applicable deletion instructions reapplied. Confidentiality and security duties continue until the data is deleted. On request, we will confirm completion or explain outstanding legally required retention.

The service has device, app and organisation deletion tools. Their availability does not imply a self-service full-workspace export exists; return requests require an agreed secure process. Closing a chat, ending billing and deleting an account are not interchangeable deletion instructions.

• Subject and purpose: in-app customer support, shared conversation management, troubleshooting context, image exchange, review-request handling and customer-enabled notifications/replies.
• Activities: collection, recording, organisation, storage, retrieval, display to authorised users, transmission, correction, restriction and deletion. Processing is ongoing as customer apps and agents use the service.
• People: app end users and the customer’s authorised owners, agents and other people whose information they submit in support content.
• Data: support identifiers, optional names/emails/user IDs and whether they were verified, custom metadata, device/app/OS/locale/timezone details, message and image content, conversation and receipt timestamps/status, review-link clicks, push tokens and routing details. Metadata may contain customer-supplied subscription context.
• Sensitive data: not specifically requested or intended. Customer must not submit special-category, criminal-offence, full payment-card or other high-risk data without separately agreed instructions and safeguards.
• Duration and retention: service term plus the agreed return/deletion period; exact production schedules and backup expiry PLACEHOLDER. Controller contact and authorised instructions contact: as recorded in the accepted order.

• Application access: organisation-scoped queries and permission checks, owner/agent roles, authenticated dashboard sessions, app and device-session authentication with hashed session credentials and short-lived access tokens, and optional identity verification signed by the customer's server.
• Application boundaries: validated requests, request limits keyed by device, app and hashed network address, uploads verified before use, short-lived signed object URLs and server-held integration credentials. Apple Push private keys and identity-verification secrets are encrypted; this does not represent blanket database encryption or end-to-end encrypted messaging.
• Deletion: scoped purge operations for devices/projects/organisations and retryable cleanup of pending deletion and stale uploads. Operational scheduling and completion monitoring must be confirmed.
• Deployment controls to complete before acceptance: HTTPS enforcement, database/object/backup encryption, administrator MFA and least privilege, patching, monitoring and log retention, backup frequency and restore testing, access reviews, incident response, confidentiality training, and regular security verification. Owners and verification records: PLACEHOLDER.

This is an incomplete inventory, not a final authorised subprocessor list. For each provider, record its contracting legal entity, role, service, data categories, storage/access countries, applicable processing agreement and transfer safeguard before acceptance.

• Application/database host: PLACEHOLDER — undecided. Receives customer records and service traffic. Coolify is deployment software and does not identify the hosting legal entity.
• Object storage and backups: PLACEHOLDER — undecided. S3-compatible software does not establish that AWS is the provider. Receives images and/or backup copies of records, depending on configuration.
• Apple Push: optional token and notification-payload delivery. Contracting entity, role, countries and safeguards: PLACEHOLDER.
• Telegram: optional support-message routing and replies through the customer’s bot/chat. Contracting entity, role, countries and safeguards: PLACEHOLDER. Messages may remain in recipients’ histories after disconnection.
• Account-side recipients to assess separately: Google (sign-in), Stripe (payments if enabled), and ipapi.co (dashboard sign-in IP location). Their legal entities, roles, locations and applicable agreements: PLACEHOLDER. These are not automatically subprocessors for all customer support content.
• Apple App Store Connect: customer-authorised source of daily sales reports and app identifiers for billing and audits, read with an encrypted key limited to the Sales and Reports role. Only daily totals per currency of connected apps are kept; other report rows are discarded on receipt. Individual purchase and customer revenue identifiers are not imported. Role, locations and safeguards: PLACEHOLDER. Stripe handles payment methods and invoices; its role is assessed separately for payment processing and its own legal obligations. AI processing is not an active data flow.

The completed DPA forms part of the accepted service agreement and survives to the extent needed to protect retained data. Nothing in it removes either party’s direct statutory responsibilities or individuals’ enforceable rights. Governing law and dispute arrangements follow the completed service agreement, subject to mandatory data-protection and transfer provisions.

Before acceptance, complete the operator and customer identities, effective date, contacts, security commitments, return/deletion schedule and authorised provider/transfer records. Do not treat this draft’s publication as a signature or confirmation that those arrangements are already in place.