Security and data safety

This page is for Jira admins and security teams deciding whether the app fits their rules.

Where Jira data goes

To one place only: the Google spreadsheet the report’s owner picks. The app can open only the files picked in Google’s own file picker (Google’s drive.file permission). It can’t see the rest of anyone’s Drive.
Each report reads Jira as the person who set it up. A sheet never shows more than that person may see in Jira. No Jira password or token is stored.
Anyone who can open the spreadsheet sees the issues it shows, even ones they can’t open in Jira. Who can open it is set in Google, with its Share button. The app says this where reports are shared.

What the app keeps, and where

The app runs on Atlassian Forge, inside Atlassian’s cloud. We run no servers of our own. It keeps:

each report’s settings (name, filter, spreadsheet and tab, columns, who sees it, its owner);
each person’s Google sign-in (a refresh token in Forge’s secret storage), until they disconnect;
the last 20 update results per report;
an activity log for Jira admins (who added, changed, took over or deleted a report, connected Google, or changed the site’s settings), for one year;
for a few minutes to three days: which issues changed (their ids and keys), and a person’s Jira groups.

It keeps no copy of what your issues say: their fields go straight from Jira to the spreadsheet. In the spreadsheet, invisible tags (Google’s developer metadata) mark the app’s columns and rows with a Jira field id or an issue id, so the app finds them after a sort. The companies that handle data for us are listed on the sub-processors page. Every week the app reports the Atlassian account ids it keeps to Atlassian. For a closed account it deletes that person’s Google sign-in and the run history of their reports, and pauses those reports until an admin takes them over. Forge deletes all of the app’s data 28 days after the app is uninstalled.

Rules a Jira admin can set

In Jira settings → Apps → Sheets sync (or Configure in Manage apps). All are off until an admin turns them on.

Who can use the app: everyone, or members of chosen Jira groups.
Who can add reports, and who reports may be shared with (everyone on the site, or chosen groups).
Google accounts that may receive Jira data: for example only addresses at your company’s domain, so nothing goes to a personal Gmail account.
How far a report’s spreadsheet may be shared in Google: as its owner likes, not with “anyone who has the link”, or only with people and groups at your allowed domains.
Fields that never leave Jira: they aren’t offered as columns and aren’t read.
Issues that leave a filter: whether their rows keep showing the issue’s latest values, or keep the values they had. Turn this off when a filter decides what may be seen, such as “Customer visible = Yes”.

The app checks these rules when a report is saved, when someone takes a report over, and at every update. So a rule you tighten applies within minutes. A report that breaks a rule stops before writing anything and shows why.

Your organisation’s app access rules

If your organisation blocks apps from some projects (Atlassian’s app access rules), Jira hides those issues from the app. The app notices this and leaves their rows in the sheet as they were, instead of treating them as gone. The report’s update says which projects were blocked.

Contact

Security questions and reports of a weakness: (the security contact address is added at launch).