Data Processing Addendum

1. Parties and formation

This Data Processing Addendum (the “Addendum”) is 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”), and the organisation that uses Dragy, or lets its employees, contractors or other personnel (“Authorised Users”) use Dragy, in connection with its business (the “Customer” or “you”).

The Addendum is incorporated into our Terms of Service (the “Terms”) whenever the Customer uses Dragy in this way; no signature is needed for it to take effect. If you need a countersigned copy, write to [email protected]. It does not apply to individuals using Dragy for personal purposes; our Privacy Policy covers them. The person accepting the Terms for the Customer confirms they have authority to bind it.

2. Definitions

• “Applicable Data Protection Law” — all data protection and privacy laws that apply to the processing of Customer Personal Data, which may include UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (PDPL); the EU GDPR (Regulation 2016/679); the UK GDPR and Data Protection Act 2018; the Swiss Federal Act on Data Protection; the laws of other GCC states, including the Saudi Personal Data Protection Law; the data protection laws of the DIFC and ADGM where they apply; and US state privacy laws.
• “Customer Personal Data” — personal data that we process on the Customer’s behalf in providing the Service, as described in Annex 1.
• “Encrypted Content” — files, file and folder names, text and links sent through the Service, which are encrypted on the sending device with keys we never hold.
• “Transfer Metadata” — the limited information we need to deliver Encrypted Content: sizes, times, sending and receiving device identifiers, wrapped keys we cannot unwrap, expiry and download counts.
• “Controller”, “Processor”, “Data Subject”, “Personal Data”, “Processing” and “Supervisory Authority” — as defined in Applicable Data Protection Law, or their closest equivalents.
• “Personal Data Breach” — 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 a Sub-processor process.
• “Service” — Dragy, as described in the Terms.
• “Sub-processor” — a third party we engage to process Customer Personal Data on our behalf.
• “SCCs” — the standard contractual clauses approved by the European Commission in Implementing Decision (EU) 2021/914; “UK Addendum” — the International Data Transfer Addendum issued by the UK Information Commissioner.

3. Roles of the parties

3.1 Customer Personal Data

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

3.2 Data we control ourselves

We act as an independent controller, under our Privacy Policy, for the data we need to run and secure the Service: Authorised Users’ account and sign-in data (email, password hash, two-step verification), device records and public keys, session records, the security activity log, IP addresses used for Nearby, rate limits and relay quotas, server and proxy logs, abuse-prevention records, support correspondence, and records we must keep by law.

3.3 What we can and cannot access

The Customer acknowledges that, by design, Encrypted Content is encrypted and decrypted only on Authorised Users’ devices and the devices they send to, and that we cannot access it in readable form. Our processing of Encrypted Content is limited to transmitting it, relaying it, holding it temporarily and deleting it. Live transfers between devices on the same network, or connected directly, do not pass through our servers at all.

3.4 Customer responsibilities

The Customer is responsible for: having a lawful basis for the transfers its Authorised Users make; giving any notices to and obtaining any consents from Data Subjects; deciding which data its personnel may move with Dragy and to whom; managing which devices and share links its Authorised Users create; keeping its own copies of all data (Dragy is not a storage or backup service); and the security of its devices.

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 first unless that law prohibits it on important grounds of public interest.

The Customer instructs us to process Customer Personal Data (a) to provide, secure and maintain the Service under the Terms and this Addendum; (b) as initiated by Authorised Users through their use of the Service, including the devices, recipients, share-link settings and features they choose; and (c) as set out in other reasonable written instructions consistent with the Terms. We will not sell Customer Personal Data, use it for advertising, use it to train any AI model, or combine it with other data except as strictly necessary to operate the Service.

We will promptly tell the Customer if, in our opinion, an instruction infringes Applicable Data Protection Law. If we cannot reasonably comply with an instruction — including one that would require us to read Encrypted Content, which we cannot do — the Customer may stop using the affected part of the Service.

5. Confidentiality and access

Everyone we authorise to process Customer Personal Data, including staff, contractors and Sub-processors, is bound by an appropriate duty of confidentiality. Administrative access to our servers is limited to personnel who need it to operate, secure or support the Service. Such access can reach Transfer Metadata and ciphertext, but not Encrypted Content in readable form, because the keys exist only on users’ devices.

6. Security

Taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing and the risks to Data Subjects, we will implement and maintain appropriate technical and organisational measures, including at least those in Annex 2. We may update them over time provided the overall level of protection is not materially reduced. The Customer is responsible for the security of its own devices, accounts, and the share links and connection codes its Authorised Users create and distribute.

7. Sub-processors

7.1 General authorisation

The Customer gives general authorisation for us to engage Sub-processors. The current list, with what each does and where, is on our sub-processor page, which forms Annex 3.

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 emailing subscribers. Where an urgent replacement is needed for security or continuity, notice may be shorter and we will explain why.

7.3 Objection

The Customer may object to a new Sub-processor on reasonable data-protection grounds by writing to [email protected] within the notice period. We will discuss it in good faith. If it cannot be resolved within a reasonable time, the Customer may stop using the affected part of the Service, and, if any fees were paid in advance for it, receive a pro-rata refund. This is the Customer’s sole remedy for an unresolved objection.

7.4 Flow-down

Each Sub-processor is bound by written terms no less protective than this Addendum, to the extent they apply to its services. We remain responsible to the Customer for each Sub-processor’s performance, subject to section 15.

8. Data subject requests

Taking into account the nature of the processing, we will help the Customer, as far as reasonably possible, to respond to Data Subjects exercising their rights. Authorised Users can view and delete their stored transfers and share links in Settings → Cloud & links, remove devices, and delete their accounts in Settings → Security → Delete account.

Because we cannot read Encrypted Content, we cannot search it for a Data Subject’s data, provide a copy of it, or correct it. Requests concerning the content of files must be handled by the Customer from its own copies and devices; we can delete specific stored transfers or share links on the Customer’s instruction. If we receive a request directly from a Data Subject that we can identify as relating to Customer Personal Data, we will refer them to the Customer.

9. Impact assessments and consultation

We will provide reasonable assistance with any data protection impact assessment or prior consultation with a Supervisory Authority that Applicable Data Protection Law requires for the Customer’s use of the Service, usually by making available this Addendum, our Security page, the sub-processor list and answers to reasonable written questions.

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, by email to the account owner or a contact the Customer designates.

10.2 Content

To the extent available, the notice will describe the nature of the breach, including the categories and approximate number of Data Subjects and records concerned; our data protection contact ([email protected]); the likely consequences — noting that Encrypted Content remains protected by end-to-end encryption unless users’ device keys were compromised; and the measures taken or proposed. Information we don’t yet have will follow in phases without undue delay.

10.3 Cooperation

We will take reasonable steps to contain, investigate and remediate the breach and help the Customer meet its own notification duties. Notifying a breach is not an admission of fault. Unsuccessful attempts that don’t compromise Customer Personal Data — such as blocked sign-in attempts, port scans or denial-of-service attempts — are not Personal Data Breaches.

11. Deletion and return

Dragy does not retain Customer Personal Data beyond delivery. Stored transfers are deleted automatically once every recipient device has received them, when a share link expires or reaches its download limit, after 24 hours if an upload is not completed, and in every case after at most 7 days (or 7 days for links). Relayed data is never stored. When an Authorised User deletes their account, their stored transfers and share links are deleted immediately.

Because data is deleted on delivery and we cannot decrypt it, there is no Customer Personal Data for us to return: the Customer’s copies remain on its own devices. On written request, we will confirm in writing that deletion has taken place. Transfer Metadata contained in server logs is deleted within [30 — confirm] days, and any copy in backups of our account database within 14 days.

12. Audits and information

12.1 Information first

We will make available the information reasonably necessary to demonstrate compliance with this Addendum. This is met first by this Addendum and its Annexes, our Security page, and our written answers to reasonable security and privacy questionnaires (no more than once a year, unless there has been a Personal Data Breach or a Supervisory Authority requires it). We do not currently hold third-party certifications or audit reports, and do not claim to.

12.2 Audits

If that information is not enough, or a Supervisory Authority requires it, the Customer (or an independent auditor bound by confidentiality who is not our competitor) may audit our compliance on at least 30 days’ written notice, no more than once in any 12 months (except after a Personal Data Breach or where an authority requires it), at an agreed scope and time, during business hours, without access to other customers’ data or our keys, at the Customer’s cost, and sharing the report with us.

13. International transfers

13.1 General

We are established in the United Arab Emirates, and our Sub-processors operate in the locations on the sub-processor page. The Customer authorises transfers to those locations, provided each complies with Applicable Data Protection Law.

13.2 EEA and Switzerland

Where Customer Personal Data originating in the EEA is transferred to us without another valid mechanism, the SCCs are incorporated by reference: Module 2 (controller to processor) or Module 3 (processor to processor) as applicable; the Customer is the data exporter and we are the data importer; clause 7 (docking) applies; under clause 9, Option 2 (general authorisation) applies with the notice period in section 7; the optional wording in clause 11 does not apply; clauses 17 and 18 select the law and courts of [Ireland]; and Annexes I and II are completed by Annex 1 and Annex 2. For Swiss transfers, the SCCs apply with the adaptations Swiss law requires.

13.3 United Kingdom

For Customer Personal Data originating in the UK, the UK Addendum is incorporated and supplements the SCCs as above. Table 1 is completed with the parties in section 1, Table 2 with the modules in section 13.2, and Table 3 with Annexes 1 to 3; either party may end it as its section 19 allows.

13.4 UAE and other GCC states

For Customer Personal Data subject to UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (PDPL), the laws of other GCC states, or the DIFC or ADGM regimes, we will transfer it out of the relevant jurisdiction only on a basis those laws recognise — such as an adequacy finding, approved contractual safeguards or a statutory exception — and take any additional steps they require. [Counsel to confirm the mechanisms available under the PDPL implementing regulations and each GCC law.]

13.5 Conflicts

If this Addendum conflicts with the SCCs or the UK Addendum, those prevail for the transfers they cover.

14. Government access requests

If we receive a legally binding request from a public authority for Customer Personal Data, we will: review its legality and challenge it where there are reasonable grounds to consider it unlawful; try to redirect the authority to the Customer; notify the Customer unless the law prohibits it; disclose only the minimum required; and keep a record. We cannot disclose Encrypted Content in readable form, and we have not built any mechanism that lets anyone bypass the end-to-end encryption. See our Law Enforcement Guidelines.

15. Liability

Each party’s liability under this Addendum is subject to the exclusions and limitations in the Terms, and references there to a party’s liability mean its aggregate liability under the Terms and this Addendum together. Nothing here limits either party’s liability to Data Subjects under the third-party beneficiary rights in the SCCs, or liability that cannot be limited by law.

16. Term and changes

This Addendum takes effect when the Customer starts using the Service for its organisation and lasts as long as we process Customer Personal Data. Sections 5, 11, 15 and 18 survive termination. We may update it to reflect changes in law, regulatory guidance or the Service, provided protection for Customer Personal Data is not materially reduced, with at least 30 days’ notice of material changes; changes required by law may take effect sooner.

17. Order of precedence

If documents conflict on the processing of Customer Personal Data, they apply in this order: (1) the SCCs and UK Addendum, where they apply; (2) this Addendum; (3) the Terms; (4) the Privacy Policy.

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 agree in writing, the courts of the Dubai International Financial Centre (DIFC). The SCCs and UK Addendum are governed by the law and courts set out in their own clauses.

19. Annex 1 — Details of processing

20. Annex 2 — Security measures

Described in more detail on our Security page.

End-to-end encryption

• Content, including file and folder names, is encrypted on the sending device with AES-256-GCM in authenticated chunks bound to their position and to the end of the stream, using fresh keys per transfer derived with ECDH P-256 and HKDF-SHA-256. Keys never reach our servers.
• Offline deliveries wrap the transfer key separately for each recipient device; share-link keys live in the URL fragment, which browsers don’t send to servers.
• Each signed-in device generates a non-extractable key pair; only the public key is registered. Devices pin each other’s keys on first use and refuse a device whose key changes.
• Transport is additionally protected by TLS (server connections) and DTLS (WebRTC).

Authentication and access control

• Passwords hashed with scrypt; common-password checks; per-account lock-out after repeated failures; equalised response times.
• Optional TOTP two-step verification with replay protection; seeds encrypted at rest with AES-256-GCM under a server master key.
• 256-bit random session tokens, stored only as SHA-256 hashes and sent as a bearer header (no cookies); recent authentication required to delete an account.
• Device removal ends the device’s sessions immediately and discards transfers waiting for it.

Abuse resistance and minimisation

• Storage quotas per account, per transfer and overall, with a free-disk floor; share links require a confirmed email.
• Rate limits on every endpoint and on real-time messages; connection caps and daily relay budgets per network address or account.
• Application logs record only method, path (without query string) and status — never credentials, tokens, link keys or bodies. IP addresses used for Nearby and limits are held in memory only.
• Received file names are sanitised against path traversal and control characters.
• The web app runs under a strict Content Security Policy with no third-party code.

Organisational measures

• Production access restricted to authorised personnel with strong authentication. [Confirm: MFA on administrative access and access review frequency.]
• Confidentiality obligations for personnel and contractors.
• Security updates for dependencies and infrastructure. [Confirm: patching cadence and dependency scanning.]
• Incident response covering detection, containment, notification under section 10 and review. [Confirm: documented plan.]
• A vulnerability disclosure programme; see our Security page.

21. Annex 3 — Sub-processors

The authorised Sub-processors, with the purpose, data and location of each, are listed on our sub-processor page, incorporated by reference. Changes follow section 7.

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