Copy for Trello®
ProductUse casesPricingFAQ
DEEN

Data Processing Agreement (DPA)

This Data Processing Agreement pursuant to Article 28 GDPR governs the processing of personal data in connection with Copy for Trello® by JDu Apps.

Data Processing Agreement (DPA)
pursuant to Article 28 of the General Data Protection Regulation (GDPR)

Version dated: 29 August 2026

between

1. Controller / Client

[Name / company of the customer]
[Address]
[Postcode City]
[Email address]

– hereinafter the “Client” or the “Controller” –

and

2. Processor

JDu Apps
Sole proprietor: Julian Dubbert
Eilenau 11
22087 Hamburg
Germany
support@copy-for-trello.com
copy-for-trello.com

– hereinafter the “Processor” –

together the “Parties”.


1. Subject matter and scope
1.1

This Agreement governs the processing of personal data by the Processor on behalf of
the Controller in connection with the use of the migration service provided by JDu Apps.

1.2

The Processor provides a technical service for the automated migration of data from
supported project management and collaboration platforms into target accounts or
target platforms designated by the Controller.

The current focus of the service is the migration of Trello® boards.

1.3

The Processor processes personal data only to the extent necessary to perform the
migration commissioned by the Controller, or where the Controller issues a
corresponding instruction.

1.4

This DPA applies only to processing activities in which the Processor processes
personal data on behalf of the Controller.

Other processing activities in which the Processor itself is a controller within the
meaning of the GDPR are not subject to this DPA.


2. Nature and purpose of the processing
2.1

The purpose of the processing is exclusively the performance of the data migration
commissioned by the Controller.

2.2

The processing may in particular include the following operations:

  • reading data from the source system,
  • transferring data via technical interfaces,
  • temporary processing and interim storage,
  • technical transformation and structuring,
  • mapping of users and objects,
  • transferring data into the target system,
  • creation or restoration of attachments,
  • repair or establishment of links,
  • technical error handling,
  • technical logging,
  • retry of failed processing steps,
  • subsequent deletion of data that is no longer required.

2.3

Processing takes place solely for the purpose of technically performing the migration
selected by the Controller.

The content processed in the course of the migration shall not be used for advertising,
profiling, or any other purposes of the Processor’s own.


3. Categories of personal data
In the course of a migration — depending on the platform selected by the Controller and
the data contained therein — the following categories of personal data may in particular
be processed:

  • names and other master data relating to individuals,
  • usernames and user identifiers,
  • email addresses and other communications data,
  • user assignments and mentions,
  • card, task and project titles,
  • descriptions and other free-text content,
  • comments and activities,
  • checklists,
  • labels and tags,
  • due dates and status information,
  • attachments, files and images,
  • links and references,
  • technical identification data,
  • other content contained in the data selected by the Controller for migration.

Where the data made available by the Controller for migration contain special categories
of personal data within the meaning of Article 9 GDPR or personal data relating to
criminal convictions and offences under Article 10 GDPR, such data may also be
processed to the extent technically required for the migration.


4. Categories of data subjects
The processing may in particular concern:

  • employees and staff of the Controller,
  • customers and prospects of the Controller,
  • suppliers and business partners of the Controller,
  • users of the platforms used by the Controller,
  • contact persons and other points of contact,
  • other natural persons whose personal data are contained in the data to be migrated.


5. Duration of the commissioned processing
5.1

The commissioned processing begins when the respective migration starts.

5.2

Processing generally ends upon completion or cancellation of the respective migration
and the subsequent deletion of personal data that are no longer required.

5.3

This DPA applies for the duration of the business relationship between the Parties. It
ends upon termination of the business relationship and cessation of the processing of
personal data by the Processor. Statutory retention obligations remain unaffected.


6. Processing on documented instructions
6.1

The Processor processes personal data solely on documented instructions from the
Controller, unless processing is required by law.

6.2

Commissioning a specific migration, selecting the data to be migrated, and designating
the target system constitute instructions of the Controller.

6.3

The Controller is responsible for the lawfulness of the processing and, in particular, for
ensuring that it is entitled to transfer and process the data.

6.4

The Processor is entitled to refuse to carry out an instruction if, in its view, the
instruction violates mandatory data protection provisions. The Controller shall be
informed of this without undue delay.

6.5

Where the Processor is required to process personal data by Union or Member State
law, it shall inform the Controller of that legal requirement before processing, unless
the law prohibits such information.


7. Confidentiality
7.1

The Processor shall ensure that persons authorised to process personal data have
committed themselves to confidentiality or are under an appropriate statutory
obligation of confidentiality.

7.2

Personal data may be made accessible only to persons who need those data to perform
their respective tasks.

7.3

Access rights are granted on a least-privilege basis and are revoked when the relevant
need ceases.


8. Data minimisation and nature of the technical processing
8.1

In designing and operating the service, the Processor takes into account the principle of
data minimisation.

8.2

Complete contents of the systems to be migrated — in particular card descriptions,
comments, custom fields and comparable content — are generally processed only
during the technical performance of the migration and are not stored permanently in
the regular application database.

8.3

Attachments and files may be stored temporarily on the file system or comparable
temporary storage for the technical performance of the migration. Such temporary
files are deleted after their processing has been completed.

8.4

Certain technical metadata may be stored temporarily for technical operation. This may
in particular include:

  • technical IDs,
  • board, card and object mappings,
  • short links and references,
  • truncated card titles,
  • usernames or user identifiers for a mapping configured by the Controller,
  • technical status information,
  • technical log information.


9. Technical and organisational measures
9.1

The Processor shall implement appropriate technical and organisational measures
pursuant to Article 32 GDPR to ensure a level of security appropriate to the risk.

9.2

The measures contemplated at the time of conclusion of this Agreement are described
in Annex 2 – Technical and Organisational Measures (TOM).

9.3

The Processor is entitled to further develop technical and organisational measures or to
replace them with equivalent measures, provided that the existing level of protection is
not materially reduced.


10. Assistance with data subject rights
10.1

Taking into account the nature of the processing and the information available to it, the
Processor shall assist the Controller in fulfilling its obligations towards data subjects
under Articles 15 to 22 GDPR.

10.2

This may in particular include:

  • providing available information,
  • assisting with the identification of stored data,
  • assisting with erasure,
  • assisting with the restriction of processing,
  • forwarding requests received directly by the Processor.

10.3

Decisions on the merits of a data subject request and the fulfilment of statutory
obligations towards the data subject remain with the Controller.


11. Assistance with security incidents and other obligations
11.1

Taking into account the nature of the processing and the information available to it, the
Processor shall assist the Controller in fulfilling its obligations under Articles 32 to 36
GDPR.

11.2

This includes in particular informing the Controller without undue delay of a personal
data breach of which the Processor becomes aware, insofar as it concerns data
processed on behalf of the Controller.

11.3

Where available at the relevant time, the information shall in particular include:

  • the nature of the security incident,
  • the categories of data concerned,
  • the groups of data subjects concerned,
  • known or suspected effects,
  • measures already taken or planned.


12. Sub-processors
12.1

The Processor may engage further processors to perform its services.

These may in particular include providers in the areas of

  • hosting and cloud infrastructure,
  • email delivery,
  • monitoring and security,
  • data processing,
  • other technical infrastructure,

insofar as they are in fact engaged as sub-processors within the meaning of Article 28
GDPR.

12.2

The sub-processors engaged at the time of conclusion of this Agreement are listed in
Annex 3 – List of Sub-processors.

12.3

The Controller grants the Processor a general authorisation to engage further
sub-processors.

12.4

Before engaging a new sub-processor or replacing an existing one, the Processor shall
inform the Controller of the intended change and give the Controller the opportunity to
object on important data-protection grounds.

12.5

The Processor shall ensure that each sub-processor is contractually bound to data
protection obligations that appropriately correspond to the obligations provided for in
this DPA.

12.6

The Processor shall bind the sub-processors it engages, by means of appropriate
contractual arrangements, to comply with the data protection requirements applicable
to the respective processing.

Before engaging them, the Processor shall adequately assess whether the respective
sub-processors provide suitable guarantees for processing in compliance with data
protection law, in particular by reviewing suitable data protection agreements,
technical and organisational measures, and other available evidence.

The Processor’s responsibility for sub-processors is limited to the selection, oversight
and contractual duties incumbent upon it under Article 28 GDPR. No guarantee is given
for every actual act of a sub-processor outside the Processor’s sphere of influence and
control.


13. Transfers to third countries
13.1

A transfer of personal data to a third country or an international organisation shall take
place only where the statutory requirements of Articles 44 et seq. GDPR are met.

13.2

Where a sub-processor processes personal data outside the European Economic Area,
this shall be indicated accordingly in the list of sub-processors or in the information
provided in that regard.


14. Deletion and return
14.1

Personal data are generally processed only for the period required to perform the
respective migration.

14.2

After completion or cancellation of a migration, temporarily stored personal data are
generally deleted within 14 days, unless a longer retention period is required by law.

14.3

Data may temporarily be contained in technical backups. Deletion from backups takes
place as part of the regular technical deletion cycles.

14.4

A separate return of the complete migration data is generally not required, because the
data are transferred into the target system designated by the Controller as part of the
commissioned migration.

14.5

Statutory retention obligations remain unaffected. Data that must be retained for a
longer period due to a legal obligation shall be deleted after expiry of the applicable
period and, during the statutory retention period, shall be processed only to the extent
required by law.

14.6

The Processor shall ensure that sub-processors generally delete or return the
Controller’s personal data after completion of their respective services in accordance
with the contractual and statutory deletion obligations applicable to them. However,
the Processor is not obliged to monitor deletion at a sub-processor beyond the control
measures that are contractually and technically available to it.


15. Demonstration and audit rights
15.1

The Processor shall make available to the Controller the information necessary to
demonstrate compliance with the obligations laid down in Article 28 GDPR.

15.2

The Processor shall support reasonable reviews and audits by the Controller insofar as
these are necessary to fulfil statutory obligations.

15.3

The Controller shall generally exercise its audit rights in the first instance by means of
appropriate documentation, evidence, information and — where available —
certifications or audit reports.

15.4

Where a more extensive review is required, the Controller may, after reasonable prior
notice, conduct an audit or have one conducted by a suitable independent auditor.

15.5

Audits shall be conducted in such a way that the Processor’s business operations, the
security of systems and the rights of the Processor’s other customers are impaired as
little as possible.

15.6

The details of an audit shall be appropriately coordinated between the Parties.


16. Data Protection Officer and data protection contact
The Processor has appointed a Data Protection Officer where such appointment is
legally required.

Data-protection-related enquiries may be directed to the following contact address:

privacy@copy-for-trello.com

Where the Controller has appointed a Data Protection Officer, the Parties may exchange
the respective contact details.


17. Amendments to the Agreement
17.1

Amendments and supplements to this DPA require written form, where legally
permissible.

17.2

The Processor may amend this DPA where this is necessary due to statutory or
regulatory changes, changes to the technical or organisational framework, or further
development of the service.

Where an amendment materially affects the rights or obligations of the Controller, the
Controller shall be informed appropriately.


18. Electronic conclusion of the Agreement
18.1

This DPA may be concluded in electronic form.

18.2

Where the DPA is concluded as part of an electronic ordering or registration process,
the Controller’s documented electronic consent shall constitute conclusion of the DPA.

18.3

In doing so, the Processor shall in particular document the applicable version of the DPA
as well as the time and attribution of the consent.

Article 28(9) GDPR expressly provides that the contract may also be concluded in
electronic form.


19. Relationship to the main agreement
19.1

This DPA supplements the main agreement between the Parties concerning the use of
the migration service.

19.2

In the event of conflict between this DPA and the main agreement, the provisions of this
DPA shall prevail with respect to the processing of personal data.

19.3

In all other respects, the provisions of the main agreement remain unaffected.


20. Governing law
German law shall apply, unless mandatory statutory provisions provide otherwise.

The statutory places of jurisdiction remain unaffected.


21. Severability
Should any provision of this DPA be or become invalid or unenforceable, the remaining
provisions shall remain unaffected.

Where legally permissible, the invalid or unenforceable provision shall be replaced by a
valid provision that most closely approximates the commercial and data-protection
purpose of the original provision.


Annex 1 – Description of the processing

1. Subject matter
Automated migration of data from supported project management and collaboration
platforms into target accounts or target platforms designated by the Controller.

The current focus is the migration of Trello® boards.


2. Purpose
Performance of the data migration commissioned by the Controller.


3. Processing operations
  • reading
  • transferring
  • processing
  • structuring
  • mapping / assigning
  • temporary storage
  • technical transformation
  • recreation in the target system
  • transfer of attachments
  • technical error handling
  • deletion


4. Categories of personal data
  • names and master data relating to individuals
  • usernames and user identifiers
  • communications data
  • email addresses
  • user assignments and mentions
  • card and task titles
  • descriptions
  • comments
  • checklists
  • labels and tags
  • due dates
  • status information
  • attachments and files
  • images
  • technical IDs and references
  • other personal data contained in the migrated content


5. Categories of data subjects
  • employees and staff
  • customers and prospects
  • suppliers and business partners
  • users of the source and target platforms
  • other persons whose personal data are contained in the migrated content


6. Duration
Processing takes place during the respective migration.

Temporarily stored data are generally deleted within 14 days after completion or
cancellation of the migration.


Annex 2 – Technical and Organisational Measures (TOM)

1. Principle
JDu Apps implements technical and organisational measures that ensure a level of
security appropriate to the risk.

The measures take particular account of the specific nature of the migration service,
namely that complete contents of the systems to be migrated are generally not stored
permanently in the regular application database.


2. Physical access control
The production application is operated on the server infrastructure of a professional
hosting provider.

Physical access to data centre and server areas is controlled by the respective hosting
provider.

JDu Apps itself has no physical access to the server hardware.


3. System access control
Administrative access to the production infrastructure is protected by appropriate
authentication and access-protection measures.

These include in particular, where used for the respective infrastructure:

  • individual user accounts,
  • secure authentication,
  • restricted administrative access,
  • SSH access via suitable authentication methods,
  • firewall rules,
  • disabling of unused network services,
  • regular security updates.


4. Data access control
Access rights to systems and data are granted on a least-privilege basis.

Access to customer data is limited to persons and processes that require it for
operation, maintenance, troubleshooting or support.

Permissions that are no longer required are revoked.


5. Tenant isolation
Data and migrations of different customers are logically separated from one another.

Access to migrations, user accounts and technical metadata is controlled on the basis
of the respective permissions.

For protected access operations, the application verifies the requesting user’s
authorisation for the requested resource.


6. Data minimisation and temporary processing
The application is designed so that complete contents of the systems to be migrated are
generally not stored permanently in the regular database.

In particular, card descriptions, comments, custom fields and comparable content may
be processed exclusively in memory during technical processing.

Attachments and files are, where required for the migration, stored temporarily and
deleted after processing.


7. Encryption and transmission security
The web application is provided via encrypted HTTPS/TLS connections.

Communication with supported APIs takes place over encrypted connections where
supported by the respective services.

Credentials, tokens and other secrets are not stored in publicly accessible areas of the
source code.


8. OAuth and access tokens
Where supported by the respective platforms, OAuth-based authorisation procedures
are used.

Customer passwords for third-party platforms are generally not stored by JDu Apps.

OAuth tokens and comparable credentials are used solely to perform the operations
authorised by the customer and are protected against unauthorised access.

Tokens that are no longer required are deleted or, where technically possible,
invalidated.


9. Deletion concept
The application uses automated or defined deletion processes.

These include in particular:

  • deletion of temporary attachments after processing,
  • deletion of temporary migration data,
  • deletion of mappings that are no longer required,
  • deletion of tokens that are no longer required,
  • deletion of technical metadata after expiry of the applicable retention period.

The regular retention period for persisted technical migration data is generally a
maximum of 14 days.


10. Logging and input control
Technical operations are logged to the extent required.

Logging serves in particular:

  • error analysis,
  • security monitoring,
  • traceability of technical operations,
  • detection of misuse,
  • stability and operation of the application.

Logs are limited to what is technically necessary.


11. Availability control
The production application is operated on professional server infrastructure.

To maintain availability, the following are used in particular, where provided for the
respective infrastructure:

  • server monitoring,
  • technical logging,
  • regular security updates,
  • backup and recovery procedures,
  • procedures for handling technical incidents.


12. Recoverability
Suitable backup and recovery procedures are used for relevant system components.

In the event of a technical outage, recovery can be performed on the basis of the
available backups and procedures.


13. Separation of development and production systems
Development and production environments are generally operated separately.

Production customer data are not used for development or testing purposes, unless
this is required for a specific operational purpose and is permissible under data
protection law.

Where possible, test data or artificially generated data are used for development and
testing.


14. Security updates and vulnerability management
Operating systems, server components and software in use are updated regularly.

Security-relevant updates are applied promptly depending on their criticality.

Security-relevant vulnerabilities are assessed and addressed within the available
technical means.


15. Security incidents
Procedures exist for the detection, assessment, containment and remediation of
security incidents.

Known personal data breaches are assessed with regard to their impact on personal
data and handled in accordance with statutory and contractual requirements.


16. Confidentiality
Persons with access to production systems or personal data are bound to
confidentiality in accordance with their tasks.

Access rights are revoked when the respective tasks cease.


17. Review and further development
The technical and organisational measures are reviewed regularly and adapted in the
event of technical, organisational or legal changes.

Changes must not result in a material reduction of the existing level of protection.


18. Review of sub-processors
Before engaging sub-processors, JDu Apps adequately reviews their data-protection
and technical frameworks. Where required, suitable data protection agreements or
data processing agreements are concluded.

In the selection process, JDu Apps particularly considers the technical and
organisational measures offered and available evidence of their implementation.

Changes to the sub-processors engaged are documented in accordance with the
provisions of the DPA and, where required, communicated to the Controller.

The sub-processors engaged are adequately reviewed on the basis of available
information and evidence.


Annex 3 – List of sub-processors

At the time of conclusion of this Agreement, the following sub-processors are engaged
insofar as required for the respective service:

Company: Hetzner Online GmbH
Purpose: Hosting, server infrastructure, and sending and receiving of emails
Nature of processing: Processing of data arising on the server infrastructure as well as email addresses and communications data required for sending and receiving emails
Location: Industriestr. 25, 91710 Gunzenhausen, Germany

Company: Stripe Technology Company Limited (STC)
Purpose: Payment processing and billing of booked services
Nature of processing: Processing of customer, payment and transaction data for the performance and documentation of payments
Location: One Wilton Park, Wilton Place, Dublin 2, D02 FX04, Ireland

This list will be updated in the event of changes in accordance with the provisions of
this DPA.

Download

You can download the DPA as a text file.

Download DPA (TXT)

We are not affiliated, associated, authorized, endorsed by or in any way officially connected to Trello, Inc. (www.trello.com).

© 2026 Copy for Trello®
Legal noticePrivacyToSDPAWithdrawal