Data processing agreement

Processor: Frederick James Dev Ltd, a private limited company registered in England and Wales, contact [email protected]. Customer: the person or organisation that accepted the Terms of Service, identified by its account and billing details. Its organisation owners are its contacts for privacy matters unless it names another. Effective date: 18 October 2026.

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 describes these measures.

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 gives general authorisation for the providers described in Schedule C. 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 or Slack workspace, 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.

Where processing involves a restricted international transfer, we will rely on an applicable transfer mechanism, such as an adequacy decision or approved contractual safeguards with any required assessment. 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. 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. Customer can delete its data at any time with the service’s deletion controls; copies in backups are removed as those backups expire.

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 when they expire; 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. For teammates who reply from a connected Slack channel: Slack user ID, display name, profile image link and email address. 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: the service term, until customer deletes the data or its organisation, plus backup expiry. Controller and instructions contact: customer’s organisation owners unless it names another.

• Application access: organisation-scoped queries and permission checks, admin/member 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 controls: encrypted transport for all traffic, administrator access limited to people who need it, patching, monitoring, backups and incident response, applied in proportion to the risks of the processing.

These providers process customer personal data, or receive it at customer’s choice, in operating the service. Details of their legal entities, locations and safeguards are available from [email protected].

• Hosting, database, object storage and backups: our infrastructure providers, which receive customer records, images, backup copies and service traffic.
• Apple Push: optional token and notification-payload delivery.
• Telegram: optional support-message and image routing and replies through the customer’s bot/chat. Messages may remain in recipients’ histories after disconnection.
• Slack: optional support-message and image routing and replies through the customer’s workspace and channel, including the profile details of teammates who reply there. Messages and files may remain in the workspace after disconnection.
• Account-side recipients to assess separately: Google (sign-in), Stripe (payments if enabled), and Cloudflare (edge network, including approximate dashboard sign-in location). These are not automatically subprocessors for all customer support content.
• Stripe sells the service as merchant of record and handles payment methods, tax and invoices; its role is assessed separately for payment processing and its own legal obligations. AI processing is not an active data flow.

This DPA forms part of the Terms of Service 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 Terms of Service, subject to mandatory data-protection and transfer provisions.