Privacy policy — Easy Reporting for Jira

⚠️ DRAFT. NOT LEGAL ADVICE. DO NOT PUBLISH AS IT STANDS.

This is a factual first draft for a solicitor to review and turn into a published policy. It was written by the product team from the code, the manifest and docs/security-model.md. It has not been reviewed by a lawyer.

Its job is to save the lawyer's time. Everything about how the software handles data should already be correct here, so the review can be about legal judgement rather than about establishing what the app does.

Every square-bracketed item is a blank that has to be filled in. The list at the end says what still has to be decided.

App: Easy Reporting for Jira, a Forge app for Atlassian Jira Cloud. Published by: easyreporting.co.uk, Unit D, 19 Heathmans Road, Fulham, London, SW6 4TJ. Contact: privacy@easyreporting.co.uk. Version: draft of 2 September 2026. Effective: 2 September 2026.

In this policy, "we" and "us" mean easyreporting.co.uk. "You" means the organisation that installs the app, and the people who use it.

The short version

Easy Reporting runs entirely inside your own Atlassian environment. We do not receive your Jira data, your uploaded files or your reports. We could not receive them: the app is built without permission to send anything to an address outside Atlassian.

So there is no copy of your data on our systems, because we do not have any systems that hold customer data. What we do hold is the account and billing information Atlassian gives us when you buy the app, and any email you send us for support.

Why this policy is short on the usual things

Most app privacy policies explain where your data is sent and who else handles it. This one cannot, because there is nowhere and nobody.

Easy Reporting is a pure Forge app. Forge is Atlassian's platform for apps that run on Atlassian's own infrastructure. Three things follow from that, and they are the reason the rest of this policy reads the way it does.

The app has no way to reach the outside world. A Forge app has to declare every outside address it wants to call. Easy Reporting declares none. There is no analytics service, no external logging, no error-reporting service, no font or image loaded from elsewhere, and no web trigger anyone could call from outside. The platform enforces this, not our good intentions.

Your data stays in a database that belongs to your installation. Each installation of the app gets its own Forge SQL database on Atlassian's infrastructure, inside your own Atlassian environment. One customer's data is never in the same database as another's. Whatever data residency and encryption Atlassian applies to your site applies to it.

We are not a processor of your personal data in the ordinary sense, because we never receive it. Your Jira data and your uploaded files stay inside the Atlassian environment you already have an agreement with Atlassian about. That agreement continues to cover where the data lives and who can reach it. There is no transfer to us to assess, no onward sharing, and no third country involved.

We are not claiming this makes us exempt from data protection law. It changes what there is to assess. Your legal team will want to reach their own view, and the facts above are the ones to reach it from.

What the app stores in your database

The app reads data from Jira and keeps a copy in your installation's own database, so that reports run quickly. Here is exactly what it keeps.

From Jira

Issues. Key, project, issue type, status, summary, parent and epic, created, updated and resolved dates, the assignee's Atlassian account id, and the issue's security level.
Field values. The app stores the value of every field it can make sense of, both Jira's own fields and your custom fields. This includes free-text fields, so text somebody typed into a field can end up stored. Only a limited length of a long text value is kept, because the column has a fixed size.
Labels, one row per label.
History. Changes to the fields the app tracks over time, so you can ask what a board looked like on a past date. Status is the main one.
Worklogs. Who logged the time, when the work happened, and how many seconds.
How many comments an issue has. A number, and nothing else. Comment text is never read into the database and there is nowhere in the schema to put it. Comment authors and comment dates are not stored either.
Sprints and versions. Names and dates, copied onto the issue.
Your field list. The name and type of every field on your site, plus previous names, so a renamed field does not break a saved report.
Project names and keys.

The app holds no permission to write to Jira. It cannot change, transition, comment on or delete a single issue.

From you

Files you upload. You can upload a CSV to bring your own data in, such as a cost-centre map, a budget or a team roster. The app reads the file, works out the type of each column, and stores the rows in your database. The file itself is not kept as a file. The values from it are.
Reports you save. The name of the report and its definition: which fields are on which shelf, which filters are set, and how it is sorted. Saved with the Atlassian account id of whoever saved it.
Settings. Site-wide things a Jira administrator sets, such as the date format.
Operational state. How far a sync has got, how much space is used, and when things last ran.

What it never stores

Comment text, comment authors or comment dates.
Attachments. The app does not have permission to read them.
Passwords or credentials of any kind. There are none to hold: Atlassian identifies the user on every request.
Anything at all on our own systems.

Personal data specifically

Jira issues contain personal data, and so do some uploaded files. This section says what happens to it.

From Jira, the personal data stored is mostly Atlassian account ids and the display names attached to them: who an issue is assigned to, who reported it, who logged time against it, and any custom field that names a person. Free-text fields can contain anything somebody typed, including names and contact details, and the app stores the value of those fields like any other.

From your uploads, it is whatever is in the file. A roster has names in it. A pay-band file has salaries in it. The app does not inspect an upload for sensitive content and does not treat one column differently from another. You decide what to upload.

All of it stays in your installation's database. None of it is sent anywhere. None of it is used to train anything, profile anybody or make an automated decision about anybody. There is no advertising and no marketing use of any kind.

Who can see what

Jira data follows your Jira permissions. Every report is narrowed to the projects the person running it may browse. The app asks Jira that question, as that person, each time a report runs. It keeps no copy of your permission scheme. If Jira cannot be asked, the report stops and says so rather than showing everything.

The answer is held for ten seconds so that one click does not become several calls to Jira. In practice, if you revoke somebody's access, a report they run in the next ten seconds may still include the project. Reports after that will not.

Uploaded files are private to the person who uploaded them, plus the accounts that person names. Nobody else can read the values, and nobody else can see that the file's columns exist. Somebody without access never learns that a column called "Salary" is there. Only the uploader can delete the file, change who can read it, or see who it is shared with. A file that is still loading is readable by nobody, including the uploader.

Saved reports are private to the person who saved them. There is no sharing and no way for an administrator to read somebody else's saved reports.

Jira administrators can turn a field off, restart a sync, see how much storage is used, and set the site date format. That is checked against Jira every time. There is no separate app administrator to appoint.

Two limits are worth stating plainly, because they affect who sees what.

Issues with a security level are left out of every report, for everybody. Jira gives an app no way to ask which security levels a particular person belongs to. Rather than guess, the app excludes every issue that carries one. This errs on the safe side, and it means some people will not see rows they are entitled to see.

Field-level visibility in Jira is not applied. Jira lets an administrator hide individual fields from some users. The app does not know about that. If somebody can see an issue, they can report on the values of the fields stored for it. If you hide a field from a group in Jira and that matters, turn the field off in the app so it is not stored at all.

Reports you download

You can export a report to CSV, and you can put a report on a Jira dashboard. An export is a normal browser download from Atlassian to your own machine. Once a file is on your machine, it is yours to look after and this policy no longer reaches it.

The app sends nothing to anybody. There is no email delivery, no notification and no inbox.

How long data is kept

History is kept for 12 months, on a rolling basis. Older status changes are deleted automatically. This is not a setting you can change.

Everything else is kept until you delete it or uninstall the app. Issue data is refreshed from Jira as issues change. If an issue is deleted in Jira, the app's copy goes at the next sync that notices.

Uninstalling the app drops the whole database with it. That is done by Atlassian's platform, not by our code. There is no retention window, no archive and no backup of your data on our side, because there is nowhere else for a copy to be.

Deleting data, and answering an erasure request

Everything below is self-service. You do not have to contact us, and there is nothing we could do that you cannot.

What you want to do	Who can do it	What happens
Delete an uploaded file	The person who uploaded it	The rows go, and the fields that read them disappear from the picker
Stop somebody reading an uploaded file	The person who uploaded it	The grant is removed and their next query cannot see it
Delete a saved report	The person who saved it	The report and its definition go
Stop storing a field	A Jira administrator	The field is turned off and its stored values are deleted
Remove everything	A Jira administrator	Uninstall the app, and the database is dropped with it

If a person asks you to erase their personal data, the practical answers are: delete or re-upload the file that names them, turn off the field that holds them, or uninstall. The app holds no separate account record for anybody, so there is no user profile to delete. A person's Atlassian account id appears only because it is on an issue, a worklog, an upload or a saved report.

We cannot action an erasure request on your database ourselves, because we cannot reach it.

Logging

The app writes operational log lines to Atlassian's log store, which is part of your Atlassian environment. These help diagnose a failed sync or a rejected upload.

Those lines are deliberately redacted, because customer data used to reach them. An error is reduced to its name and its message. Its stack, its cause and its attached properties are dropped, since that is where a database driver or an HTTP client keeps a copy of the offending data. Anything in quotation marks is replaced, because a quoted value in a database error is the value itself. Every line is capped in length.

This was a deliberate change. A rejected upload used to log the cells it was complaining about, which put real salaries and dates of birth into a log. It no longer does. The detailed message still goes back to the person who caused the error, on screen, which is where it belongs.

We do not receive these logs.

What we hold about you

We hold no customer content. We do hold the following.

Purchase and licence information from Atlassian. When you buy or trial the app through the Atlassian Marketplace, Atlassian gives us the information a seller needs: your organisation, your licence, and contact details for the people Atlassian names as your technical and billing contacts. Atlassian collects the money and pays us. We use this to know who our customers are, to get paid, and to contact you about the app.

Support correspondence. If you email us for help, or use the support form at easyreporting.co.uk/support, we have your name, your email address, the Jira site address if you gave one, and whatever you put in the message.

The form sends that message to our support address using Cloudflare's email service, and the message is then delivered into a Google mailbox that we read. So a support enquiry is held by Cloudflare in transit and by Google at rest, and it stays in that mailbox until we delete it.

Please do not send us exports of real customer or employee data. We do not need them, and we would rather not hold them. We cannot see your Jira data, so a description of the problem is all we ever work from.

[DECIDE: how long the support mailbox keeps correspondence, and say the period here. "Until we delete it" is honest and not good enough for a policy.]

[CONFIRM WITH ATLASSIAN AND WITH THE LAWYER: exactly which fields the Marketplace passes to a partner, and how our role is described for that data. This paragraph is written from how the Marketplace generally works, not from a document we have checked.]

No cookies and no tracking by us. The app's interface sets no analytics cookie and loads nothing from a third party. Atlassian's own cookies and logging apply to the page it runs in, and Atlassian's privacy policy covers those.

Support access

We cannot read your data. There is no back door, no support login and no administrative view of a customer's database. If a problem could not be diagnosed without seeing your data, we would not be able to diagnose it.

That is a limitation of the product, not a permission we hold. If we ever need something to reproduce a problem, we will ask you to send us a description or a screenshot with sensitive parts removed, and you can decide.

Subprocessors

For your Jira data, there are none. Nobody outside your Atlassian environment receives it, in any form, for any purpose, including us. The app is built without permission to reach any address outside Atlassian, so this is not a promise about our conduct — it is a property of how the app is built.

Atlassian is not a subprocessor of ours either. Atlassian is your provider, and your data stays inside the environment you already have with them.

Two companies are involved if you contact us, and they are not involved in your Jira data at all:

Cloudflare hosts easyreporting.co.uk and carries the mail your support form sends.
Google holds the mailbox that support mail is delivered into.

Neither can reach your Jira data. They handle only what you choose to put in a message to us. We list them because "there are no subprocessors" would be a convenient thing to say and is not true of us as a company, even though it is true of the app.

[LAWYER: confirm the right term for Atlassian's role in the contractual chain, and whether Cloudflare and Google should be named as subprocessors or described some other way given they touch support correspondence rather than the data the app processes.]

Security

Your data sits in an Atlassian-hosted database with Atlassian's encryption and region handling. On top of that, the app:

holds only read permissions on Jira, and no write permission of any kind;
asks Jira who you are on every request, and never accepts an account id sent by the browser;
checks project access against Jira for every report;
enforces upload permissions inside the database query, not by hiding things on screen;
declares no outside address it can call.

To report a security problem, email privacy@easyreporting.co.uk.

Changes to this policy

If we change this policy we will update the page and change the date at the top. [DECIDE: whether material changes are also emailed to the Marketplace technical contact.]

Contact

easyreporting.co.uk, Unit D, 19 Heathmans Road, Fulham, London, SW6 4TJ. Email privacy@easyreporting.co.uk.

Decisions needed from you

These are commercial or legal calls the product team should not make alone.

Controller and processor language. This draft states the facts and says we never receive customer data. It deliberately avoids labelling ourselves as a processor or as a controller of customer content. Confirm the wording you want, and whether the policy should say what we are, rather than only what we do not do.
Data processing agreement. Enterprise buyers will ask for one even though we receive no customer data. Decide whether to offer a short DPA that says so, refuse, or point at Atlassian's. Having an answer ready is worth more than the document.
The Marketplace data paragraph. Confirm what Atlassian actually passes to a partner and how that is described. Marked above.
Article 27 representatives. Whether one is needed depends on where the entity is established and where customers are.
Retention of support email. How long we keep a support mailbox, and where it lives. If the mailbox is a hosted helpdesk product, that provider is a processor of ours and has to be named here. Today there is nothing to name, and that changes the day a helpdesk is bought.
The 12-month history window. Decide whether it is stated as a promise we are bound to, or as a description of current behaviour that could change. The product enforces 12 months today.
Notice of changes. Whether a material change is emailed or only posted.
Whether to publish this at a stable URL of our own. The Marketplace form needs a URL that will not move.

Facts the lawyer should not soften

These were expensive to get right and are the reason the policy is credible.

Comment counts are stored. Comment text, authors and dates are not. An earlier draft of the listing claimed comment dates were stored, and that was wrong.
There is no external network access at all. Not "we choose not to".
Issues with a security level are excluded from every report, for everybody.
Field-level visibility in Jira is not applied.
We cannot read a customer's data, even to help them.

Back to Easy Reporting