Memo Labs
Privacy Policy, CRA Clock for Jira
Effective 7 September 2026. Last updated 8 September 2026.
This policy explains how the Atlassian Marketplace app CRA Clock for Jira ("the app") handles data. It is provided by Memo Labs ("we", "us"), the business name of Guillaume Flambard, a sole trader (entreprise individuelle) established in France and the Marketplace Partner that publishes the app. Atlassian does not license the app to you and is not responsible for how we process your data.
The short version. The app runs entirely inside Atlassian's infrastructure and makes no outbound calls to any server we or anyone else operates. It stores Atlassian account IDs, Jira issue keys, timestamps, and the report text your team types. We cannot read that stored data. We can see operational logs for 30 days, and your site administrator can switch that off.
1. Who is responsible for what
Under the GDPR and comparable laws, the customer that installs the app is the controller of the data the app processes, because the customer decides which incidents to record and what to write in a report. Memo Labs acts as a processor, acting on the customer's instructions as expressed through their use of the app.
Atlassian provides the platform the app runs on, including the storage described below. Atlassian's own handling of that data is governed by Atlassian's agreements with the customer, not by this policy.
If you need a Data Processing Addendum under Article 28 of the GDPR, write to contact@memolabs.dev and we will sign one.
2. What the app stores
The app writes one record per Jira issue on which an incident has been qualified. That record contains:
| Data | Why it exists | Personal data? |
|---|---|---|
Atlassian accountId of the user who qualifies an incident, saves a draft, records a fix
date, or marks a report as sent |
Article 14 of Regulation (EU) 2024/2847 is about proving what was known and when. A record that does not say who acted proves nothing. | Yes, it is a pseudonymous identifier attributable to a person |
Jira issue key, for example SEC-142 |
One issue, one incident. The key is how the record is found again. | No |
| Timestamps: awareness date, fix availability date, draft and submission times, escalation times | Every deadline in Article 14 is derived from these. | No |
| Two booleans recording the Article 3(42) qualification, plus which track was chosen | They decide whether an obligation exists at all. | No |
| The text your team types into the report fields | These are the fields Article 14 requires for each stage. | Only if your team types personal data into them. See section 3. |
| An append-only event log of the above actions | A file that can be rewritten is not evidence. | Yes, it contains account IDs |
The app stores the account ID, not the display name and not the email address. Names are resolved for display by Jira at the moment you look at the panel, from data Jira already holds.
The app also posts comments on the Jira issue before each deadline. Those comments contain the deadline, the time remaining, and the name of the report that is due. They contain no personal data, and they live in Jira under your own retention rules, not ours.
3. Free text is your responsibility
The report fields are free text. If your team writes the name of a customer, an employee, a researcher who reported the vulnerability, or an IP address into them, that personal data is stored with the record. The app cannot detect this and does not try to.
Article 14 does not require you to identify individuals in a report. Where you can describe an incident without naming a person, do that.
4. Where the data is stored, and who can reach it
All app data is held in Forge hosted storage, which is Atlassian infrastructure. The app's manifest
declares no external permissions, which means the platform itself prevents the app from making a
network call to any host outside Atlassian. This is the condition of the Runs on Atlassian programme, and it
is verifiable: the manifest is reviewed by Atlassian at every deployment.
The practical consequences:
- We operate no server, no database, and no analytics for this app. There is nowhere for your data to be copied to.
- We use no sub-processors, because there is no processing outside Atlassian's platform.
- We cannot read the contents of your incident records. We have no interface that exposes them.
- Data residency, where your Atlassian subscription includes it, is Atlassian's to apply and applies to the app's storage as part of your instance.
5. Logs
The app writes short operational log lines: the number of open incidents processed in a scheduled run, the number of escalation comments posted, and the issue key plus HTTP status code when a comment cannot be posted. It does not log report contents, account IDs, or qualification answers.
Atlassian retains these logs for 30 days and makes them available to us in the Atlassian developer console, which is how we diagnose a failure you report. Access is granted automatically when the app is installed, and your site administrator can disable it in the Atlassian admin console at any time. If you disable it, we lose that visibility and will ask you for details instead.
6. How long the data is kept
Incident records persist for as long as the app is installed, because the point of the app is to hold a record you may need to show a market surveillance authority years later. The app deletes nothing on its own, and it does not expire old incidents.
When the app is uninstalled, Atlassian soft deletes the app's storage and retains it for the remainder of its standard retention period before permanent disposal. If the app is reinstalled and a request is made within 21 days of uninstallation, the new installation can be relinked to the previous data. After that window, treat the data as gone.
Export your dossiers before uninstalling if you need to keep them. The app provides an export for exactly this purpose.
7. Your rights
If you are an individual whose account ID appears in an incident record, the controller is the organisation whose Jira site holds the record, not us. Address any request to access, correct, or erase that data to that organisation. Their Jira administrator can act on it directly.
If a customer instructs us to assist with such a request, we will, to the extent the platform allows. Write to contact@memolabs.dev.
8. Cookies and tracking
The app sets no cookies of its own, and contains no analytics, advertising, session recording, or fingerprinting. Cookies present while you use Jira are set by Atlassian.
This website sets no cookies either.
9. Security incidents
If we become aware of a personal data breach affecting app data, we will notify affected customers without undue delay and provide what we know, so that the customer can meet its own notification duties as controller.
10. Changes to this policy
We will update this page when the app's data handling changes, and change the date at the top. Material changes, meaning any new category of data or any processing outside Atlassian's infrastructure, will be announced in the app's Marketplace release notes before they take effect.
11. Contact and identity of the processor
Memo Labs is the business name of Guillaume Flambard, a sole trader
(entreprise individuelle) established in France under SIREN 924 107 469.
The processor is that natural person; there is no separate company.
Business address: 27b rue du Surmelin, 75020 Paris, France.
Email: contact@memolabs.dev.
We have not appointed a Data Protection Officer, because the app's processing is neither large scale nor systematic monitoring within the meaning of Article 37 of the GDPR. Address any data protection question to the email above.