This page sets out how BLOOMLOGIC LTD handles personal data on behalf of customers using Canopy. It is written to answer what a procurement or privacy review needs to know, with the detail that data protection law requires of a processor.
Atlassian does not impose a data processing agreement in a set form on apps sold through its Marketplace. It makes each app's publisher responsible for its own commitments to customers, consistent with Atlassian's rules on customer data. This page is ours. It is the Data Protection Addendum named in our Provider-Specific Terms, and so forms part of the agreement under which you use Canopy (see our Terms page at https://bloomlogic.co.uk/terms).
Roles
You are the controller. Your organisation decides what work is recorded in your Jira site and why. If you hold that work as a processor for a client of yours, you are the processor and we are your sub-processor; this page then applies in the same way.
We are the processor, and only for what Canopy does inside your site, on your instruction. Installing the app and using it is that instruction; we have no other purpose for your data and no independent use of it.
What we commit to as processor. We process personal data only on your documented instructions, including concerning international transfers, unless the law requires otherwise; where the law allows, we will tell you of that requirement before processing. We will tell you immediately if, in our opinion, an instruction infringes data protection law. Taking account of the processing and the information available to us, we will help you meet your obligations under Articles 32 to 36 of the UK GDPR or the EU GDPR, as they apply. We impose equivalent data protection obligations on our sub-processors and remain responsible for their performance. Anyone we authorise to process the data is bound by confidentiality.
Subject matter and duration
Displaying and editing the structure of the work in your Jira project, for as long as the app is installed, and afterwards for the retention periods described under "Return and deletion". Our obligations on this page continue while any of the personal data is retained.
Nature and purpose of the processing
Reading issues and the links between them so the project can be shown as a hierarchy; creating, renaming, re-parenting, reordering, archiving and deleting issues at the direction of the signed-in user; linking an issue newly created in Jira under a parent to that parent, written by an open board as the person viewing it, on a project using Canopy's own hierarchy; storing saved Views, Branches, palettes, templates, baselines and preferences; and the app's diagnostic log and usage counters described under "What we can see".
Types of personal data
- Jira account identifiers of people using the app, including in the app's log and in the record that counts each person once for the usage counters (see "What we can see")
- Names and avatars of the signed-in person and of people work is assigned to
- Anything your own people have typed into the Jira fields Canopy displays — issue summaries and descriptions are free text, so whatever is written there is processed as part of showing it
The agreement under which you use Canopy prohibits processing Sensitive Data, as the standard terms define it (special categories of personal data among them), through Canopy. That includes Sensitive Data in the Jira fields Canopy reads.
Categories of data subject
Your employees, contractors and anyone else with access to your Jira site, and anyone named in the content of your issues.
Sub-processors
Atlassian Corporation and its affiliates. We have chosen no others.
Atlassian hosts the app on its Forge platform, holds everything the app stores, and keeps the app's log and usage counters. We engage no analytics provider, no error-reporting service, no hosting company, no content delivery network and no AI service of any kind.
This is a consequence of how the app is built rather than a promise we maintain by hand: Canopy makes no network connection outside Atlassian, and an automated check refuses to release a build that tries to.
We will tell customers before adding any sub-processor of our own choosing, with enough notice to object. Atlassian chooses its own suppliers for the platform the app runs on; they are listed at https://www.atlassian.com/legal/sub-processors.
What we can see
We cannot open your issues. Atlassian keeps the app's own log for 30 days and lets us read it: Canopy writes account identifiers and project and issue keys there when work is changed or archived; when a card keeps disagreeing with Jira it adds the card's key and the differing values of fields such as its status, dates and estimate — never its title, description or the people on it; a refused save never quotes the name typed for a saved View, Branch, palette or template. Usage counters in Atlassian's app metrics, ten of them in six kinds — a person's first edit, their return within a week of it, a person opening Canopy in a week, the size of a project as one of five bands, a picture exported, and the note for a Jira administrator copied — carry only their name and the number one. So that each person is counted once, the app keeps a record per person of which counters have counted them, the day of their first edit and the last week they were counted, until their account is reported closed or the app is removed; a project's record holds only the day its size was counted.
International transfers
Everything the app stores stays on Atlassian's platform, held where your site's data residency setting places it. Atlassian's own processing of that data is covered by Atlassian's data processing terms for apps built on Forge.
One thing does leave Atlassian's platform: we read the app's log from the United Kingdom. That log holds account identifiers and issue keys, as set out under "What we can see". We copy none of it into any system of ours.
Where EU GDPR transfer rules apply to that access, we rely on the European Commission's decision that the United Kingdom protects personal data adequately (Commission Implementing Decision (EU) 2021/1772, as renewed in December 2025). If that decision stops covering the access, we will suspend it before continuing without a valid transfer basis, unless another lawful mechanism, with any safeguards it requires, is already in place.
Atlassian decides where it keeps the app's log; your site's data residency setting does not cover it. Atlassian's data processing terms with us include standard contractual clauses for the transfers they cover.
Security measures
- No external connections. The app reaches no service outside Atlassian, and this is enforced automatically on every release, not merely intended.
- No infrastructure of ours. There is no server, database or backup of ours that could be breached, misconfigured or subpoenaed.
- **Every change to your work uses the signed-in person's own Jira permissions.** Canopy cannot change an issue that person could not change directly in Jira. Two small writes are the app's own: the note on a project recording that it uses Canopy's own hierarchy — the choice and when it was made, naming nobody — written only for a person Jira confirms may edit issues there or for a project admin switching the project back to Jira's own tree, and a regular clean-up that removes a closed account's identifier from Canopy's archive marks. The clean-up runs as Canopy, with nobody signed in, so it cannot reach an item that issue security hides from Canopy itself: on such an item a closed account's identifier stays in the archive mark, readable in Jira by anyone who can see the item.
- One stated limit: restricted items. Where Jira hides some work items from some people (issue security), Canopy's Archive activity record, its shared record of recent moves and its kept baselines are kept for the whole project and do not follow that rule. A person Jira hides an item from can still learn that it exists, its key, where it sits, when it was moved or archived, and who did it; and, for a baseline kept on it, the baseline's name, when it was kept and by whom. On such a project Canopy tells each person so, once. Templates are the one saved thing that keeps titles, so a template saved for the team is refused if any of its work items is restricted; one saved for yourself is read by you, and goes into the data download described under "Return and deletion", titles of restricted work items included. Canopy says so when you save one that holds a restricted item.
- Requests are checked against the project they claim to come from, so a request cannot reach another project's stored settings.
- Least privilege in what is stored. Saved Views and preferences are held against a Jira account identifier, not against a name or an email address. The one name kept is a baseline's creator, shown in the baselines list; it is erased with the account.
Assisting you
We will help you, within a reasonable time, to:
- Answer a request from an individual for access, correction, deletion or a copy of their data
- Complete a data protection impact assessment or a security questionnaire
- Investigate an incident affecting data processed through the app
Personal data breaches
If we become aware of a breach affecting personal data processed through Canopy, we will notify you without undue delay and in any event within 72 hours of becoming aware, with what we know, what we are doing, and what we recommend you do. We will not wait until we have the full picture before telling you.
We will also tell Atlassian within 48 hours of suspecting such an incident, as our agreement with Atlassian requires. If a notice to you would name Atlassian, Atlassian may need to approve that wording first; that approval will never delay telling you that an incident has happened.
Return and deletion
Uninstalling the app does not erase what it stored at once. Canopy keeps running until the subscription or trial ends, plus 60 days, unless an admin removes it at once; then Atlassian deletes it. Atlassian says it keeps the stored data for 28 days after that deletion; when it, and Atlassian's backups of it, are finally destroyed is set by Atlassian's own retention policy. With your consent we can ask Atlassian to recover it, if the request reaches Atlassian within 21 days of the deletion. Recovery is not guaranteed. Your Jira work is not affected — the hierarchy is held in Jira's own issue links and properties, so it remains readable in Jira and by any other tool, with or without us.
To have the data back, a Jira admin (a user holding Jira's Administer Jira permission) opens Canopy's menu and chooses Download Canopy's data: one machine-readable file per project, holding everything Canopy keeps for it — saved Views, Branches, palettes and templates (everyone's, private ones included, with the titles a template keeps even of work items Jira hides from the admin), kept baselines, the Archive activity record, each person's settings and the list of people Canopy holds anything about. It works after a subscription lapses too. Download first, then uninstall to delete.
We hold no separate copy to return or destroy, because we never hold one.
When a person's Atlassian account is closed, Canopy erases what it holds about them without being asked: on Atlassian's required schedule, normally weekly, it reports the account identifiers it stores to Atlassian, as Atlassian requires, and for each one Atlassian says is closed it deletes that person's own records and removes their identifier from shared ones. The app's log ages out on Atlassian's 30-day retention. This erasure runs only while the app is installed: what Canopy wrote into Jira stays there after an uninstall, including the account identifier of whoever archived an item, on that item's archive mark.
When Canopy deletes one of its own stored records — a saved View you delete, or a closed person's records during this erasure — the app can no longer read or restore it. Atlassian keeps a deleted copy, and its backups, for a limited time so that it can recover from accidents, then destroys them.
Audit
We will make available the information needed to show that we meet the obligations on this page and our obligations as a processor under data protection law, and answer reasonable questions and security questionnaires in writing. In deciding whether more is needed, you may take into account Atlassian's certifications and audit reports for the platform Canopy runs on.
If that is not enough to satisfy you, or a regulator requires it, you may audit how we process your personal data, yourself or through an independent auditor you choose who is bound by confidentiality. We may raise reasonable, documented concerns about an auditor's independence, confidentiality or conflicts of interest, including that the auditor competes with us; we will work with you to address them, but the final choice of auditor is yours.
Ordinarily, you will give us 30 days' written notice and conduct no more than one audit in any 12 months. Both limits give way to shorter notice or further audits reasonably needed after a personal data breach, where there are signs that we are not meeting our obligations, or where a regulator requires it. You bear your own costs and your auditor's; we do not charge for our time.
We operate no data centres or servers. Our direct access to your personal data is through the app's diagnostic log; an audit may cover our processing through Canopy, the controls and procedures around it, and that access. Audits will normally be carried out remotely. Where remote evidence is not enough, we will cooperate with an in-person inspection reasonably needed to verify compliance, under proportionate confidentiality, security and non-disruption arrangements, and with any inspection a regulator requires. For Atlassian's infrastructure, we will help you obtain Atlassian's audit reports and other relevant information.
Requests to privacy@bloomlogic.co.uk.