Privacy policy

Nothing leaves your Atlassian site

• Version 1.2 is effective from 3 September 2026 and supersedes version 1.0.
• Ganttry 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. A static Forge web trigger accepts authenticated approval and policy commands but has no read route and returns no plan data.
• It does hold personal data — Jira account ids, display names, when individual people are away, and actor ids in approval, revision, policy and audit records. That is stated below in full rather than waved at, because an app that draws and governs a chart of who is doing what could not honestly claim otherwise.

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 does not change any of that.

• We are a processor

  We publish software that processes customer data to provide the scheduling and governance 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, logs and web-trigger transport. 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 reads from Jira

Across 13 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 every export you produce 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.

• An issue's history, on request

  The changelog of an issue on the chart, when somebody asks for time in status. One issue at a time, capped, and only on a button press.

• 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 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'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.

• allocations:{scope}

  Multi-resource assignments and daily effort contours by task.

• teams:{scope}

  Team membership, sprint cadence, capacity and completed-sprint history.

• automation-state:{scope}

  The last 100 approval requests and 200 notifications, including requester and reviewer account ids.

• enterprise-site-policy / enterprise-plan-policy:{scope}

  Versioned site defaults, locks, per-plan inheritance and the administrators who changed them.

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

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

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

  The last 100 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.
• A person's display name is stored alongside their availability so the screen can still list somebody who has left the site. Nothing else about them is stored — no email address, no avatar, no group membership, no time zone.
• None of it is profiling, and none of it is used to measure anybody. Availability changes where that person's own bars fall and nothing else: Ganttry does not move other people's work to cover for them, and it does not report on individuals to anyone who could not already run the same query in Jira.

Every key Ganttry 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, per scenario. Ganttry's opinion about the dates, not Jira's.

• scenarios:{scope}

  The scenario names, and which one is open.

• 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 works out where the bars go, and what individual rows want.

• personalallocations:{scope}

  Multi-resource assignments and daily effort contours by task.

• personalteams:{scope}

  Team membership, sprint cadence, capacity and completed-sprint history.

• portfolio-levels:{scope}

  The configured issue-type hierarchy above Epic.

• risks:{scope}

  Delivery risks and mitigation notes.

• program-releases:{scope}

  Program releases composed from Jira versions in several projects.

• three-point:{scope}

  Optimistic, most-likely and pessimistic estimates by task.

• portfolio-strategy:{scope}

  Portfolio scoring, objectives, key results and Jira work links.

• automation-config:{scope}

  Versioned notification settings and approval requirements.

• personalautomation-state:{scope}

  The last 100 approval requests and 200 notifications, including requester and reviewer account ids.

• approval-claim:{scope}:{purpose}:{requestId}

  Single-use decision and consumption claims, retained for 365 days.

• approval-policy-change:{scope}:{version}

  A single-use claim preventing two integrations from advancing the same policy version.

• personalenterprise-site-policy / enterprise-plan-policy:{scope}

  Versioned site defaults, locks, per-plan inheritance and the administrators who changed them.

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

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

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

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

• 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.

• api-replay:* / api-rate:*

  Hashed integration request/plan identifiers and fixed rate slots, with a ten-minute TTL.

Nothing here is written back to Jira. A dragged bar, a baseline and a working calendar are Ganttry'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, integration-route/outcome, 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 does not copy them to another vendor.

Does the integration API expose plan data?

No. The static Forge web trigger accepts approval decisions and approval-policy configuration only. HMAC binds method, path, installation, canonical plan, role, timestamp, request id and body; five-minute timestamps, single-use replay claims and fixed 30/10 requests-per-minute route limits fail closed. Responses are predeclared status bodies with no read route.

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 can only name one, and it is not ours to choose.

• Plan, approval, policy, revision and audit records are in-scope for app data residency and reside in installation-scoped Forge hosted storage. Jira and Confluence installations have separate 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 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, approval policy/state, enterprise policy, revision history, audit events and their chain head, API replay/rate claims, environment secrets and Forge logs. Those exclusions prevent a restore from repointing a site, replaying another reader's state, or reviving security-control records.

There is no customer-configurable retention setting. Plan values last until reset, overwritten or uninstall; revision and approval histories keep 100 entries, notifications keep 200, approval claims expire after 365 days, integration replay/rate claims after ten minutes, audit events after 365 days, and Forge logs follow Atlassian's current availability window (documented as 30 days). Site/plan policy lasts for the installation unless changed.

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 exports the plan-scoped parts listed in its schema, not every personal or administrative record. Administrator-only audit exports cover their separate bounded history. Contact your administrator and the address below for records outside those exports.

• Erasure

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

• Rectification

  Authorized planners can correct supported plan values; policy administration requires its separate administrator permission. Audit events and immutable approval claims are not editable through ordinary product controls. Rights requests involving those records 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 is a business tool, sold to 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.
• No payment data of any kind reaches us. Atlassian bills for the app; we never see a card.

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.2 · 3 September 2026Added content-free Forge telemetry, the static command API, the complete storage and retention inventory, enterprise policy history, and administrator audit events.
• 1.0 · 24 August 2026First published.