Data Processing Addendum

1. Parties and formation

This Data Processing Addendum (the “Addendum”) is entered into between [Nexlla Creative Agency — registered legal name], a [Legal form] registered under licence number [Trade licence number] with [Licence issuing authority], with its address at [Registered address — street, building, city, Emirate, United Arab Emirates], trading as Nexlla Creative Agency (“we”, “us” or “our”), and the business customer that has accepted our Terms of Service (the “Customer” or “you”).

This Addendum is incorporated into, and forms part of, the Terms whenever a Customer — a company, partnership, public body, school, charity or other organisation — uses Inboxy, or permits its employees, contractors or other personnel (“Authorised Users”) to use Inboxy, in connection with that organisation’s business. No separate signature is needed for it to take effect. If your organisation needs a countersigned copy for its records, please write to [email protected] and we will provide one in the same terms.

This Addendum does not apply to individuals who use Inboxy for their own personal purposes. In that case we act as a controller and our Privacy Policy describes how we handle personal data.

The person accepting the Terms on behalf of the Customer confirms that they have authority to bind the Customer to this Addendum.

2. Definitions

Capitalised terms not defined here have the meaning given in the Terms. In this Addendum:

• “Applicable Data Protection Law” means all data protection and privacy laws that apply to the processing of Customer Personal Data under the Terms, which may include UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (PDPL); the EU General Data Protection Regulation 2016/679 (“EU GDPR”); the EU GDPR as it forms part of UK law together with the UK Data Protection Act 2018 (“UK GDPR”); the Swiss Federal Act on Data Protection; the data protection laws of the other Gulf Cooperation Council states, including the Kingdom of Saudi Arabia’s Personal Data Protection Law; the data protection laws of the Dubai International Financial Centre and the Abu Dhabi Global Market where they apply; and any law that amends or replaces them.
• “Customer Personal Data” means personal data that we process on behalf of the Customer in providing the Service, as described in Annex 1.
• “Controller”, “Processor”, “Data Subject”, “Personal Data”, “Processing” and “Supervisory Authority” have the meanings given in Applicable Data Protection Law, or their closest equivalents.
• “Personal Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data that we, or one of our Sub-processors, process.
• “Service” means Inboxy, including its web app, desktop and mobile apps, Slack app, Telegram bot and related services, as described in the Terms.
• “Sub-processor” means a third party that we engage to process Customer Personal Data on our behalf.
• “SCCs” means the standard contractual clauses approved by the European Commission in Implementing Decision (EU) 2021/914, as amended or replaced from time to time.
• “UK Addendum” means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.
• “Connected Service” means a third-party service an Authorised User chooses to connect to Inboxy, such as a mail provider, calendar, Slack or Telegram. A Connected Service is not our Sub-processor; see section 3.

3. Roles of the parties

3.1 Customer Personal Data

For Customer Personal Data, the Customer is the controller (or, where the Customer is itself acting for another controller, a processor), and we are the Customer’s processor (or sub-processor). Each party will comply with the obligations that Applicable Data Protection Law places on it.

3.2 Data we control ourselves

We act as an independent controller, and our Privacy Policy applies, for the limited personal data we need to run our business and keep the Service secure, including: account and sign-in identifiers; authentication records (password hashes, passkey public keys, two-factor settings); session and device records; security event and audit logs; abuse prevention and rate-limiting data; server request logs; support correspondence; and records we must keep to meet our legal obligations. We will process this data only for those purposes and in line with Applicable Data Protection Law.

3.3 Connected Services

When an Authorised User connects a mailbox, calendar or messaging service, Inboxy exchanges data with that provider at the user’s direction. Those providers — for example Google, Microsoft, Apple (iCloud), Yahoo, Fastmail, Proton (through Proton Mail Bridge), CalDAV servers, Slack, Telegram and Gravatar — act under their own terms with the Customer or the Authorised User. They are not our Sub-processors and we are not responsible for their processing.

3.4 Customer responsibilities

The Customer is responsible for: having a lawful basis for the processing it instructs; giving any notices to, and obtaining any consents from, Authorised Users and other Data Subjects that Applicable Data Protection Law requires; deciding which mailboxes and features its personnel may use, including whether Cloud AI may be enabled; the accuracy of the data it provides; and configuring and using the Service’s security features, such as two-factor authentication and passkeys, in a way that is appropriate for its risks.

4. Scope and instructions

We will process Customer Personal Data only on the Customer’s documented instructions, unless a law to which we are subject requires otherwise. In that case we will tell the Customer about the legal requirement before processing, unless that law prohibits us from doing so on important grounds of public interest.

The Customer instructs us to process Customer Personal Data: (a) to provide, secure, maintain and support the Service in accordance with the Terms and this Addendum; (b) as initiated by Authorised Users through their use of the Service, including the settings and features they choose (for example, the selected AI mode, notification preview level, rules, labels and connected integrations); and (c) to comply with other reasonable written instructions from the Customer that are consistent with the Terms. The Terms, this Addendum and the Customer’s configuration of the Service are the Customer’s complete instructions at the date of this Addendum.

We will not: sell or rent Customer Personal Data; use it for advertising or for building advertising profiles; use it to train, fine-tune or improve any artificial intelligence model, whether ours or a third party’s; or combine it with personal data from other customers except as strictly necessary to operate the Service (for example, aggregated, non-identifying operational metrics).

We will promptly tell the Customer if, in our opinion, an instruction infringes Applicable Data Protection Law, and we may suspend that instruction until the Customer confirms or changes it. If we cannot reasonably comply with an instruction, the Customer may terminate the affected part of the Service as its sole remedy.

5. Confidentiality

We will make sure that every person we authorise to process Customer Personal Data — including our staff, contractors and Sub-processors — is bound by an appropriate duty of confidentiality, whether contractual or statutory. Access is limited to personnel who need it to provide, secure or support the Service, and only to the extent they need it.

Routine operations do not require access to message content. We will access Customer Personal Data in readable form only to provide support an Authorised User has asked for, to investigate a security incident or abuse, or to comply with law, and only to the minimum extent needed.

6. Security

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing, as well as the risks to Data Subjects, we will implement and maintain appropriate technical and organisational measures to protect Customer Personal Data. These include, at a minimum, the measures described in Annex 2.

We may update those measures from time to time as technology and threats change, provided the updates do not materially reduce the overall level of protection. The current overview is also published on our Security page.

The Customer is responsible for the security of its own systems, devices and accounts, for its Authorised Users’ choice of sign-in methods, for keeping recovery codes safe, and for any data it removes from the Service (for example, through exports).

7. Sub-processors

7.1 General authorisation

The Customer gives us general authorisation to engage Sub-processors. The Sub-processors we currently use, what each does and where it processes data are listed on our sub-processor page, which forms Annex 3 of this Addendum.

7.2 Notice of changes

We will give at least 30 days’ notice before a new Sub-processor starts processing Customer Personal Data, by updating the sub-processor page and by emailing Customers who have subscribed to updates as described on that page. Where we need to replace a Sub-processor urgently to protect the security or continuity of the Service, we may give a shorter notice, and we will tell the Customer as soon as reasonably possible and explain why.

7.3 Objection

The Customer may object to a new Sub-processor on reasonable grounds relating to data protection by writing to [email protected] within the notice period. We will discuss the objection in good faith and, where we can, offer a reasonable alternative — for example, a configuration that avoids the Sub-processor (such as using on-device AI or turning AI off instead of Cloud AI). If we cannot resolve the objection within a reasonable time, the Customer may terminate the affected part of the Service by written notice, without penalty, and, if any fees have been paid in advance for the terminated part, receive a pro-rata refund of them. This is the Customer’s sole remedy for an unresolved objection.

7.4 Flow-down and responsibility

We will enter into a written agreement with each Sub-processor that imposes data protection obligations no less protective than those in this Addendum, to the extent they apply to the services the Sub-processor provides. We remain responsible to the Customer for the performance of each Sub-processor’s obligations, subject to section 15.

8. Data subject requests

Taking into account the nature of the processing, we will help the Customer, by appropriate technical and organisational measures and as far as reasonably possible, to respond to requests from Data Subjects to exercise their rights under Applicable Data Protection Law, such as access, rectification, erasure, restriction, portability and objection.

The Service provides self-service tools for many of these requests: Authorised Users can view and correct their data in the app, export their data (JSON and mbox) from Settings, disconnect mail accounts, and delete their Inboxy account under Settings → Security → Delete Inboxy account. Where these tools are not enough, the Customer may ask us for further reasonable assistance.

If we receive a request directly from a Data Subject that we can identify as relating to Customer Personal Data, we will not respond to it ourselves (except to direct the Data Subject to the Customer, or where the law requires us to) and will forward it to the Customer without undue delay. Assistance that goes beyond the self-service tools may be charged at reasonable cost, which we will agree with the Customer in advance.

9. Impact assessments and consultation

Taking into account the nature of the processing and the information available to us, we will provide reasonable assistance to the Customer with any data protection impact assessment, and with any prior consultation with a Supervisory Authority, that Applicable Data Protection Law requires in relation to the Customer’s use of the Service. We will usually do so by making available this Addendum, our Security page, our sub-processor list and our answers to reasonable written questions. Assistance beyond that may be charged at reasonable cost agreed in advance.

10. Personal data breaches

10.1 Notice

We will notify the Customer of a Personal Data Breach without undue delay, and in any event within 72 hours, after becoming aware of it. We will send notice to the account owner or the contact the Customer has designated to us for this purpose, and we may also show it in the Service.

10.2 Content of the notice

To the extent the information is available, the notice will describe:

• the nature of the Personal Data Breach, including, where possible, the categories and approximate number of Data Subjects and records concerned;
• the name and contact details of the person who can give more information (our data protection contact is [email protected]);
• the likely consequences of the Personal Data Breach; and
• the measures we have taken or propose to take to address it, including measures to reduce its possible adverse effects.

Where we cannot provide all of this information at once, we will provide it in phases as it becomes available, without further undue delay.

10.3 Response and cooperation

We will take reasonable steps to contain, investigate and remediate the Personal Data Breach, and we will cooperate with the Customer and provide reasonable assistance so that it can meet any obligation to notify Supervisory Authorities or Data Subjects. Unless the law requires otherwise, we will not notify the Customer’s Data Subjects or a Supervisory Authority about a breach of Customer Personal Data on the Customer’s behalf without first consulting the Customer.

Our notification of, or response to, a Personal Data Breach is not an acknowledgement of fault or liability. Unsuccessful attempts or activities that do not compromise the security of Customer Personal Data — such as blocked sign-in attempts, pings, port scans or denial-of-service attempts — are not Personal Data Breaches.

11. Deletion and return

Before the Service ends, the Customer and its Authorised Users can retrieve Customer Personal Data with the Service’s export tools, which produce a JSON and mbox archive. Exports are streamed directly to the user and are not written to disk on our servers, and stored mail credentials and tokens are never included.

When an Authorised User deletes their Inboxy account, or when the Customer’s use of the Service ends and the affected accounts are closed, we delete the corresponding Customer Personal Data. Account deletion destroys the user’s wrapped data key and deletes their vault directory straight away (“crypto-shredding”), which makes all of that user’s encrypted data permanently unreadable, and removes the related rows from our control database. Encrypted copies in our backups also become unreadable once the key is destroyed, and they rotate out of our backup set within 14 days.

When a single mail account is disconnected rather than the whole Inboxy account, the Service keeps its data in a restorable state for 7 days, then purges the synced data and, for Google accounts, revokes our access grant.

We may keep Customer Personal Data after the Service ends only where the law requires it. In that case we will keep it confidential, protect it in line with this Addendum and process it only for the purpose the law requires. On written request, we will confirm in writing that deletion has taken place.

12. Audits and information

12.1 Information first

We will make available to the Customer the information reasonably necessary to demonstrate our compliance with this Addendum. The Customer agrees that this obligation will first be met by: this Addendum and its Annexes; our Security page; any summaries of independent security assessments or third-party audit reports we hold at the time (such as a Google CASA assessment summary), shared under confidentiality; and our written answers to the Customer’s reasonable security and privacy questionnaires, which we will provide no more than once a year unless there has been a Personal Data Breach or a Supervisory Authority requires it.

12.2 On-site audits

If the information above is not enough to demonstrate compliance, or a Supervisory Authority requires it, the Customer (or an independent auditor appointed by it, who is not our competitor and who is bound by confidentiality) may carry out an audit, including an inspection, on these conditions:

• the Customer gives at least 30 days’ written notice and a proposed scope, and the parties agree the scope, timing and duration in advance;
• audits take place no more than once in any 12-month period, except following a Personal Data Breach or where a Supervisory Authority requires it;
• audits are carried out during normal business hours, in a way that minimises disruption to our business and does not compromise the security of the Service or of other customers’ data, and auditors comply with our reasonable security and site policies;
• the Customer bears its own costs and the auditor’s costs, and reimburses our reasonable costs of supporting an audit that goes beyond the information described in section 12.1;
• all information disclosed during the audit is our confidential information and may be used only to verify compliance with this Addendum; and
• the Customer shares a copy of any audit report with us, free of charge.

No audit gives access to other customers’ data, to our encryption keys, or to information we are legally bound to keep confidential.

13. International transfers

13.1 General

We are established in the United Arab Emirates and our Sub-processors operate in the locations shown on the sub-processor page. The Customer authorises us and our Sub-processors to transfer Customer Personal Data to those locations, provided that each transfer is made in compliance with Applicable Data Protection Law.

13.2 Transfers from the EEA and Switzerland

To the extent we process Customer Personal Data originating in the European Economic Area, and the transfer to us is not covered by an adequacy decision or another valid mechanism, the SCCs are incorporated into this Addendum by reference and apply as follows: Module 2 (controller to processor) where the Customer is a controller, and Module 3 (processor to processor) where the Customer is a processor; the Customer is the data exporter and we are the data importer; the optional docking clause (clause 7) applies; under clause 9, Option 2 (general written authorisation) applies with the notice period set out in section 7; the optional wording in clause 11 does not apply; under clauses 17 and 18, the SCCs are governed by, and disputes are resolved by the courts of, [Ireland]; and Annexes I and II of the SCCs are completed with the information in Annex 1 and Annex 2 of this Addendum. For transfers subject to the Swiss Federal Act on Data Protection, the SCCs apply with the adaptations required by Swiss law, with the Swiss Federal Data Protection and Information Commissioner as competent supervisory authority.

13.3 Transfers from the United Kingdom

To the extent Customer Personal Data originates in the United Kingdom, the UK Addendum is incorporated into this Addendum by reference and supplements the SCCs as described above. Table 1 is completed with the parties’ details in section 1, Table 2 with the modules and options selected in section 13.2, and Table 3 with Annexes 1 to 3 of this Addendum; for Table 4, either party may end the UK Addendum as allowed by its section 19.

13.4 Transfers from the UAE and other GCC states

To the extent Customer Personal Data is subject to UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (PDPL), the personal data laws of the Kingdom of Saudi Arabia, Qatar, Bahrain, Oman or Kuwait, or the data protection laws of the Dubai International Financial Centre or the Abu Dhabi Global Market, we will transfer it out of the relevant jurisdiction only on a basis those laws recognise — such as an adequacy finding by the competent authority, appropriate safeguards (including standard contractual clauses or binding terms approved or recognised by that authority), or a statutory exception — and we will put in place any additional measures or registrations those laws require. [Counsel to confirm the transfer mechanisms currently available under the PDPL implementing regulations and each GCC law.]

13.5 Other jurisdictions and conflicts

Where another Applicable Data Protection Law requires a specific transfer mechanism, the parties will cooperate in good faith to put it in place. If there is a conflict between this Addendum and the SCCs or the UK Addendum, the SCCs or the UK Addendum prevail for the transfers they cover.

14. Government access requests

If we receive a legally binding request from a public authority for access to Customer Personal Data, we will:

• review the legality of the request and challenge it where, after careful assessment, we conclude there are reasonable grounds to consider it unlawful;
• try to redirect the authority to request the data directly from the Customer;
• promptly notify the Customer, unless the law prohibits it — and if it does, use reasonable efforts to obtain a waiver of the prohibition;
• disclose only the minimum amount of data permitted when responding; and
• keep a record of such requests.

We have not built any mechanism designed to let authorities bypass our security measures.

15. Liability

Each party’s liability arising out of or relating to this Addendum, whether in contract, tort or any other theory of liability, is subject to the exclusions and limitations of liability in the Terms, and any reference in the Terms to the liability of a party means its aggregate liability under the Terms and this Addendum together. Nothing in this section limits either party’s liability to Data Subjects under the third-party beneficiary rights in the SCCs, or any liability that cannot be limited under Applicable Data Protection Law.

16. Term and termination

This Addendum takes effect when the Customer accepts the Terms and starts using the Service for its organisation, and it stays in force for as long as we process Customer Personal Data. It ends automatically when the Terms end and all Customer Personal Data has been deleted or returned in accordance with section 11. Sections that by their nature should survive — including sections 5, 11, 15 and 18 — survive termination.

We may update this Addendum where it is needed to reflect changes in Applicable Data Protection Law, a decision of a Supervisory Authority or court, or changes to the Service, provided that the update does not materially reduce the protection given to Customer Personal Data. We will give at least 30 days’ notice of material changes. Changes required by law may take effect sooner.

17. Order of precedence

If there is a conflict between the documents that govern the processing of Customer Personal Data, they apply in this order: (1) the SCCs and the UK Addendum, where they apply; (2) this Addendum; (3) the Terms; and (4) our Privacy Policy. Otherwise, the Terms remain unchanged and in full force.

18. Governing law

This Addendum is governed by the laws of the United Arab Emirates as applied in the Emirate of Dubai, and the parties submit to the jurisdiction of the courts of Dubai, United Arab Emirates, or, where both parties agree in writing, the courts of the Dubai International Financial Centre (DIFC). The SCCs and the UK Addendum are governed by the law, and subject to the courts, set out in their own governing-law and jurisdiction clauses, as completed in section 13.

19. Annex 1 — Details of processing

20. Annex 2 — Security measures

We implement the following technical and organisational measures. They are described in more detail on our Security page.

Encryption

• Message content, triage results, drafts, voice profiles, settings, profile photos, OAuth tokens and mail passwords are encrypted at rest with AES-256-GCM envelope encryption.
• Each user has their own data key, wrapped by a master key held outside the database in a secret manager.
• Additional authenticated data binds every ciphertext to the user, table and column, so ciphertexts cannot be swapped between users or fields.
• The ciphertext format is versioned and supports key rotation.
• Data in transit is protected with HTTPS/TLS. Connections to mail servers use TLS verified against the server hostname.

Tenant isolation

• Each user’s mail, credentials and settings live in their own vault file (in a directory named by a keyed hash of the user id, with owner-only permissions), encrypted under that user’s data key. The control database holds identities only.
• Request handlers can reach data only through the vault opened from the authenticated session. No API accepts a user id, and identifiers belonging to other users return “not found”.
• Automated cross-tenant attack tests replay every identifier-bearing route.

Access control and authentication

• Passwords hashed with scrypt and a per-user salt; minimum 10 characters; checked against a common-password list.
• Passkeys (WebAuthn) and time-based two-factor authentication (TOTP) with 10 single-use recovery codes.
• Lockout with exponential backoff per account and per IP address, constant-duration authentication responses, and identical behaviour for unknown email addresses.
• Step-up re-authentication for sensitive actions, such as pairing a device or deleting an account.
• Session tokens are random 256-bit values stored only as SHA-256 hashes, sent in __Host- HttpOnly, Secure, SameSite=Strict cookies on the web. Mobile apps use a short-lived access token held in memory and a rotating, single-use refresh token kept in the iOS Keychain or Android Keystore; reuse of a refresh token revokes the device.
• Cross-site request forgery checks on every state-changing cookie request.
• Device pairing codes are 40-bit, single-use, valid for 5 minutes and stored as keyed hashes; pairing is rate-limited and requires step-up.
• Users can see, rename and revoke each signed-in device, and a security audit log records sign-ins and other security events.

AI processing

• Users choose Cloud AI, on-device AI (Ollama) or AI off. The Customer can direct its personnel to use on-device AI or AI off.
• Before any text is sent to the cloud AI provider, a redaction step replaces email addresses, phone numbers, card numbers, IBANs, government identifiers, API keys, tokens, passwords and signed URLs with placeholders, which are restored locally afterwards.
• AI produces drafts only; nothing is sent without a user action. Automations never act on model output alone.
• Customer Personal Data is never used to train AI models.

Application and content security

• Email HTML is sanitised and rendered in a sandboxed frame with a strict content security policy; remote images go through a proxy that blocks tracking pixels and strips cookies and referrers.
• Every outbound request built from user input or email content (image proxy, unsubscribe, autodiscovery, CalDAV, custom IMAP/SMTP hosts) is checked against server-side request forgery, including DNS-rebinding protection.
• Slack requests are verified by signature and timestamp; Telegram requests by secret token; bot accounts link by one-time code and receive summaries by default.
• User-supplied patterns are length-capped and screened for catastrophic backtracking; uploads are checked by file signature and size.

Data minimisation and logging

• Sender and sign-in email addresses are stored as keyed hashes for lookups, not in plain text.
• Server logs record request paths, times and status codes only — no query strings, bodies, tokens, cookies or email addresses.
• Push tokens are stored encrypted in the user’s vault and removed on sign-out or when invalid. Users choose how much message content appears in notifications.

Availability, backups and deletion

• Encrypted nightly backups (AES-256-GCM, with a key derived from the master key), the newest 14 kept and copied off-host; the master key is stored separately from backups.
• Account deletion destroys the user’s wrapped data key and vault (crypto-shredding).

Organisational measures

• Access to production systems restricted to authorised personnel on a need-to-know basis, with strong authentication. [Confirm: access review frequency and MFA enforcement for administrative access.]
• Confidentiality obligations for all personnel and contractors with access to Customer Personal Data.
• Security patching of dependencies and infrastructure. [Confirm: patching cadence and dependency scanning process.]
• Incident response procedure covering detection, containment, notification under section 10 and post-incident review. [Confirm: documented incident response plan.]
• Due diligence and written data protection terms for every Sub-processor.
• An independent security assessment as required for Google’s restricted Gmail scope (CASA). [Confirm: assessment tier and date.]
• A responsible disclosure programme; see our Security page.

21. Annex 3 — Sub-processors

The list of authorised Sub-processors, with the purpose, data processed and location of each, is maintained on our sub-processor page and is incorporated into this Addendum by reference. Changes follow the procedure in section 7.

Questions about this Addendum, or need a countersigned copy? Write to [email protected].