Privacy policy

Nothing leaves your Atlassian site

• Version 1.0 is effective from 15 October 2026. It covers Ganttry Lite, the free edition of Ganttry; Ganttry has its own policy.
• Ganttry Lite runs on Atlassian's own infrastructure as a Forge app. It reads your Jira, works out a schedule, and stores what it worked out in Forge app storage inside your Atlassian site.
• Nothing it reads or stores is transmitted to a server or analytics vendor of ours. Content-free operational events stay in Forge logs. It has no web trigger, no integration API and no Confluence or Rovo module.
• It does hold personal data — Jira account ids, display names, when individual people are away, and actor ids in chart, revision and audit records. That is stated below in full rather than waved at.

Who is what

The first question a data protection review asks, and the one that decides what every later answer means.

• You are the controller

  The data is your employees', your projects' and your customers'. You decide what goes into Jira, who may see it, and how long you keep it. Installing Ganttry Lite does not change any of that.

• We are a processor

  We publish software that processes customer data to provide the scheduling features described here. The app also produces bounded operational events for reliability and security. We do not use customer data for advertising, profiling or unrelated purposes.

• Atlassian is the sub-processor

  Atlassian hosts the app's compute, KVS and logs. It is the only infrastructure sub-processor declared for app processing. The applicable Forge terms and DPA, as well as your Atlassian agreement, govern that platform processing; support correspondence is a separate channel.

What Ganttry Lite reads from Jira

Across 17 read endpoints, all of them as the signed-in user — so the app sees exactly what the person looking at the chart could already see in Jira, and nothing that their permissions do not already give them. The endpoint-by-endpoint list is on the security page. In terms of what it means:

• Issues and their scheduling fields

  Keys, summaries, issue types, statuses and status categories, start and due dates, estimates and time spent, story points, sprints, fix versions, parents and issue links. This is what a bar on a chart is.

• Who work belongs to

  The assignee of each issue: their Jira account id and their display name. Rows are grouped and labelled by them, so these appear on the chart and in the CSV you export from it.

• Who work could belong to

  When the assignee menu is opened, the account ids and display names of people Jira says may be assigned work in that project. Jira's own answer, per project and per user.

• Configuration, not content

  Field definitions, link type definitions, project and filter listings, boards and the filters behind them, and the issue types a project offers. Definitions and names, with no issue data in them.

Yes, and here is exactly which

We are not going to tell you Ganttry Lite processes no personal data. It processes some, it is a bounded list, and the claim worth making is the narrow one: none of it goes anywhere. The records below are the parts of Ganttry Lite's storage that are about people rather than work.

• visit:{scope}:{accountId}

  A Jira account id, and what that person last saw on this chart, so “what changed since you last looked” can be answered. One record per reader per chart.

• people:{scope}

  Per person: their Jira account id, their display name, the dates they are away, the days of the week they work, the hours a day they give this plan, and their allocation.

• chart:{scope} / chart-summary:{scope} / chart-project:{projectKey}

  Each chart's name, source, creator and optional lead, the counts and dates the Charts list shows, and which chart a project belongs to.

• chart-prefs:{accountId}

  Which charts a person starred and when they last opened each, so the Charts list can sort them. One record per person.

• audit-head:{scope} / audit:{scope}:{sequence}

  A 365-day tamper-evident event chain for Jira-changing actions, including actor account id, result, correlation id and hashes but no Jira payload.

• head:{scope} / revision:{scope}:{revision}

  The last 200 plan revisions and before/after snapshots, including the actor account id.

• Every person reference is keyed by Jira's account id and never by display name. That is a privacy decision as much as a correctness one: two people on a site of any size can share a name, and resolving one at write time is how somebody's record gets attached to a stranger.
• An availability record stores a person's display name alongside their account id so the screen can still list somebody who has left the site. That record does not store an email address, avatar, group membership or time zone; chart, revision and audit records can also contain the account ids stated in the inventory.
• None of it is profiling or used for employee performance measurement. Availability and working weeks can affect capacity and plan dates, but Ganttry Lite does not infer productivity, performance or reasons for absence.

Every key Ganttry Lite writes

All of it in Forge app storage, inside your Atlassian site. This is the whole list, not a representative sample — the app keeps its keys in one file for the same reason this page prints them in one table.

• personalvisit:{scope}:{accountId}

  A Jira account id, and what that person last saw on this chart, so “what changed since you last looked” can be answered. One record per reader per chart.

• personalpeople:{scope}

  Per person: their Jira account id, their display name, the dates they are away, the days of the week they work, the hours a day they give this plan, and their allocation.

• baseline:{scope} / baseline-index:{scope} / baseline:{scope}:{id}:{chunk}

  The legacy single-record baseline or the current frozen plan snapshots and bounded chunk index, used to measure the current plan.

• overrides:{scope}:{scenarioId}

  The bars somebody dragged, for the chart's one plan. Ganttry Lite's opinion about the dates, not Jira's.

• publish:{scope}

  The last publish, kept so it can be undone. One, not a stack.

• calendar:{scope}

  The team's working days and non-working dates.

• markers:{scope}

  Dates the team wrote on the chart.

• views:{scope}

  Named ways of looking at the plan.

• columns:{scope}

  Which Jira fields the chart shows as columns.

• linkopts:{scope}

  What each arrow means — its dependency type and its lag. Jira has no field for either.

• scheduling:{scope}

  Whether Ganttry Lite works out where the bars go, and what individual rows want.

• workload-effort:{scope}

  How Workload counts effort: story points or an estimate, hours per point, and how unestimated work is shown.

• personalchart:{scope} / chart-summary:{scope} / chart-project:{projectKey}

  Each chart's name, source, creator and optional lead, the counts and dates the Charts list shows, and which chart a project belongs to.

• personalchart-prefs:{accountId}

  Which charts a person starred and when they last opened each, so the Charts list can sort them. One record per person.

• personalaudit-head:{scope} / audit:{scope}:{sequence}

  A 365-day tamper-evident event chain for Jira-changing actions, including actor account id, result, correlation id and hashes but no Jira payload.

• personalhead:{scope} / revision:{scope}:{revision}

  The last 200 plan revisions and before/after snapshots, including the actor account id.

• gantt-project-library:{projectKey}

  Whether an allowed Jira project is hidden from the app's project library.

• portfolio

  Which projects the portfolio page is showing.

• source

  Whether the chart is drawn from projects, a filter or a query.

• seen:{scope}

  Which projects a filter or query turned out to cover last time it ran. A cache, rebuilt by the next load.

• jira-change-journal entity / jira-change:{index}

  Ids of recently changed Jira issues and their project keys, from Jira's own change events, so an open chart knows what to reload. The last ten chunks are kept.

Nothing here is written back to Jira. A dragged bar, a baseline and a working calendar are Ganttry Lite's opinion about your data rather than facts about your issues, which is why they live beside your Jira instead of in it. What does reach Jira is the separate, listed, deliberate act of publishing.

Nobody

Is any of it sold?

No. We do not sell app customer data or use it for advertising or profiling.

Is any of it shared with third parties?

The app has no declared external egress or external analytics recipient. Atlassian hosts the processing. Customer-requested downloads and information you choose to send to support are outside the app's automated data path.

Is there analytics or telemetry?

Yes, inside Forge logs only: bounded chart-load, incident and degradation events. Fields are fixed to surfaces, correlation ids, status/duration and row-count buckets, and complete/partial results. They reject issue content, keys, project keys, JQL, account ids, request bodies, secrets and browser stacks. There is no analytics egress or separate vendor.

Are logs shared?

Forge writes invocation logs and the bounded events described above. They are available through Atlassian's developer-console and customer log-sharing controls and retained on Atlassian's schedule, currently documented as 30 days. Ganttry Lite does not copy them to another vendor.

Can anything outside Jira read a plan?

No. Ganttry Lite registers no web trigger and has no integration API, so nothing outside your Jira can send it a command or read a plan from it.

Would you hand it over if compelled?

We assess lawful requests under the applicable legal process and notify the customer where permitted. Jira source records remain with the customer and Atlassian. The absence of a separate vendor database is not a promise that no accessible logs or support records could ever be subject to a request.

The country your Jira is in

The Marketplace Partner Agreement asks every listed app to name the countries its data is stored in. Ganttry Lite can only name one, and it is not ours to choose.

• Plan, chart, revision and audit records are in scope for app data residency and reside in installation-scoped Forge hosted storage.
• Atlassian supports region pinning and migration for eligible Forge hosted storage. Your administrator should verify the app's actual residency status in Atlassian administration; an unpinned site is not a promise of storage in a particular country.
• Content-free Forge logs and platform operational metadata are outside the app's in-scope residency record. Their locations, availability and platform backups follow Atlassian's terms and controls. Customer-downloaded files and support correspondence are also outside Forge storage pinning.
• Ganttry Lite has no separate vendor-operated customer-data backend or declared app egress. Applicable international-transfer obligations and safeguards must still be evaluated under the Forge and customer agreements; this architecture does not make them inapplicable.

What happens when you uninstall

A chart backup deliberately excludes Jira records, the installation-wide source, the `seen` cache, per-user visits and chart preferences, revision history, audit events and their chain head, the Jira change journal, environment secrets and Forge logs.

There is no customer-configurable retention setting. Plan values last until reset, overwritten or uninstall; revision histories keep 200 entries, audit events expire after 365 days, the Jira change journal keeps its last ten chunks, and Forge logs follow Atlassian's current availability window (documented as 30 days).

And who can actually act on them

GDPR, the UK GDPR and the CCPA give people rights over data held about them. Because we hold none of it, almost every one of them is exercised in your own site, by you, without waiting for us.

• Access and portability

  The in-app backup saves the plan-scoped parts listed in its schema, not every personal or administrative record. Contact your administrator and the address below for records outside it.

• Erasure

  Supported plan values can be removed through the relevant feature. Revision and audit records and logs follow the retention schedule above. Uninstall follows Atlassian's soft-deletion and recovery lifecycle; it is not immediate physical erasure.

• Rectification

  Authorized planners can correct supported plan values. Audit events are not editable through ordinary product controls, and rights requests involving them need individual review.

• Who to ask

  Start with your Jira administrator to verify authority and identify the installation and records. Contact us for assistance with unsupported requests or platform retention. We do not provide support impersonation or promise that every record can be changed in the app.

Under the CCPA we are a service provider, we sell nothing and share nothing, so there is no opt-out to offer you — there is nothing to opt out of.

Things this app never asks for

• Ganttry Lite is a business tool, used by organisations, and is not directed at children. No age is collected and none is inferred.
• No special category data under GDPR Article 9 is asked for, and none is stored in any field the app writes. A person's non-working days record that they are not working, not why — there is no field for a reason and the app never asks for one.
• Ganttry Lite is free and has no billing, so no payment data of any kind reaches us.

Who to write to

What changed, and when

A term is never edited in place. When one changes, the version goes up and the change is written here.

1.015 October 2026

First published, for Ganttry Lite.