Acuerdo de tratamiento de datos

This Data Processing Agreement ("DPA") forms part of the Terms of Service between ShieldSync (the "Processor") and your organisation (the "Controller"), and records the parties' agreement on the processing of personal data under Article 28 of the GDPR. Where this DPA and the Terms of Service conflict on a data protection matter, this DPA governs.

1. Scope

This DPA applies where and to the extent that ShieldSync processes personal data on the Controller's behalf in providing the service.

Local peer-to-peer syncing falls outside this DPA, because files move directly between the Controller's own devices over an encrypted connection and never reach our servers. Nothing here applies to data we never receive.

2. Details of the processing

Required by Article 28(3). This section is the description the Controller can copy into its own Article 30 record.

3. Our obligations as processor

• Documented instructions. We process personal data only on the Controller's documented instructions, which include this DPA, the Terms of Service, and the Controller's use of the service's own features. We will not transfer personal data to a third country except on those instructions or where required by EU or Member State law — in which case we will tell the Controller first, unless that law forbids it.
• Unlawful instructions. If we consider an instruction from the Controller to infringe the GDPR or other EU or Member State data protection law, we will inform the Controller without delay and may suspend performance of that instruction until it is withdrawn or amended.
• Confidentiality. Everyone we authorise to process personal data is bound by a duty of confidentiality, whether by contract or by statute, and that duty survives the end of their engagement. Access is granted only to those who need it to operate the service.
• Security. We implement the technical and organisational measures required by Article 32. In practice: file contents are encrypted on the user's device with AES-256-GCM before upload and we never hold the keys; passwords are converted to a verifier on the device using Argon2id and never reach us; filenames are encrypted client-side when filename protection is enabled; transport is over TLS; access to production systems is restricted and authenticated; and retention limits are enforced in code rather than by policy alone.

4. Sub-processors

The Controller gives general authorisation for us to engage sub-processors, subject to a written agreement with each of them imposing the same obligations as this DPA. The current list is maintained at shieldsync.dk/sub-processors and is the authoritative version; this DPA does not restate it, so the two can never disagree.

We will give the Controller at least 30 days' notice before appointing a new sub-processor, during which the Controller may object on reasonable data protection grounds. We remain fully liable to the Controller for a sub-processor's performance of its obligations.

5. Assisting with data subject requests

We assist the Controller in responding to requests under Chapter III of the GDPR, by appropriate technical and organisational measures and insofar as possible. Concretely, the service provides:

• Access and portability — a one-click export of everything we hold about an account, as structured JSON.
• Erasure — account deletion that removes the account record and every stored object, and per-item deletion for individual files and folders.
• Rectification — account details are editable by the user directly.
• Restriction — access can be revoked per collaborator, per device, and per session.
• Records — on request we can enumerate the storage keys, sizes and timestamps we hold for an account, and the devices and sessions attached to it.

6. Assisting with security and impact assessments

Taking into account the nature of the processing and the information available to us, we assist the Controller in complying with Articles 32 to 36 — security of processing, breach notification, data protection impact assessments, and prior consultation with a supervisory authority. In practice this means answering security questionnaires honestly, providing the architectural detail a DPIA needs, and supplying the breach information described in the next section.

7. Personal data breaches

We will notify the Controller without undue delay after becoming aware of a personal data breach affecting personal data processed on the Controller's behalf. We notify the Controller; we do not notify the Controller's supervisory authority or contact the Controller's data subjects on their behalf, as those decisions are the Controller's to make under Articles 33 and 34.

Our notification will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed — so the Controller can meet its own Article 33(3) obligations without a second round of questions. Where the full picture is not yet available we provide information in phases rather than delaying the first notification.

We maintain a written breach procedure and an internal register of every breach, including those we were not required to report.

8. Deletion or return of data

At the end of the provision of services, the Controller chooses whether we delete or return the personal data, and we delete any existing copies unless EU or Member State law requires us to keep them.

• Return is available at any time and does not depend on termination: the export produces the account's records as JSON, and the files themselves are already present in readable form on the Controller's own devices, because that is how the product works.
• Deletion removes the account record, every associated row, and every stored object. We keep a record that the deletion occurred, because Article 5(2) requires us to be able to demonstrate it. That record holds the date, a one-way fingerprint of the account's email address, the account's former internal number, and counts of what was removed. It contains no name, no address, and nothing about the files.

If the Controller makes no choice, we delete the data once the retention windows in our privacy notice expire. Deleted content may persist briefly in the cloud trash and in routine backups until those rotate; it is not restored to service and is removed on the normal schedule.

9. Audits and information

We make available to the Controller all information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates. In the ordinary case we expect to satisfy this by answering questions directly and in writing. We do not currently hold a SOC 2 report or ISO 27001 certificate and do not claim one; our compliance section of our security page states plainly what we do and do not have.

10. International transfers

We process personal data in the European Union and commit to keeping our own infrastructure there. One sub-processor transfers outside the EEA today: Stripe Payments Europe, Limited (Ireland) may transfer payment-related data to its group in the United States, relying on the Commission’s standard contractual clauses and, where applicable, the EU–US Data Privacy Framework. That transfer covers billing identity and payment data only — Controller file content is encrypted client-side and never reaches Stripe.

For any further transfer to a country the European Commission has not recognised as providing adequate protection, the parties adopt the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914, module two (controller to processor), incorporated into this DPA by reference. Where a sub-processor is located outside the EEA, that fact and the mechanism relied on are stated on our sub-processors page.