Privacy Policy

1. Who we are

This Privacy Policy explains how ITSM Ltd (“we”, “us”, “our”), a company registered in England and Wales under company number 17339600 with its registered office at 167-169 Great Portland Street, 5th Floor, London, W1W 5PF, handles personal data in connection with Concessa (the “App”), an application distributed through the Atlassian Marketplace.

We are not required to appoint a Data Protection Officer. Enquiries about this policy should be sent to the data protection contact above.

Statement required by Atlassian. ITSM Ltd, and not Atlassian, is responsible for the privacy, security and integrity of any End User Data processed by us or by the App.

2. Scope of this policy

This policy applies to the App only. It does not apply to:

• Atlassian’s own products and services (Jira, Jira Service Management, Atlassian account and related services), which are governed by the Atlassian Privacy Policy;
• our public website, which is governed by a separate website privacy notice; or
• any other application we publish, each of which has its own policy.

3. How the App is hosted — and why this matters

The App is built entirely on Atlassian Forge, Atlassian’s serverless application platform. This has a direct and material consequence for your privacy:

• The App runs on compute infrastructure operated by Atlassian. We do not operate any servers, databases or hosting infrastructure for the App.
• All data the App stores for its own use is held in Forge hosted storage inside Atlassian’s cloud environment. The App also writes into your own Jira site: comments, always (section 5.2), and, only where a project administrator switches on publishing to Jira, a small set of status values on each change’s issue (section 7).
• The App declares no external egress domains in its manifest. The Forge platform blocks outbound network traffic to undeclared destinations by default. Consequently, the App does not transmit your data to us or to any third party.
• We have no routine access to your data. We cannot browse, export or query the contents of your Atlassian site or the App’s stored data. The only circumstances in which we see your data are set out in section 5.4 below, and in the platform logs described in section 5.6.

4. Our role under data protection law

Our role differs depending on the data concerned.

4.1 Where we act as a processor. In respect of personal data contained within your Atlassian site that the App reads, writes or stores (see sections 5.1 to 5.3), you — the Atlassian customer whose site the App is installed on — are the controller and we act as a processor on your instructions. Atlassian acts as a sub-processor in that chain, because it provides the hosting and storage on which the App depends. Our processing on your behalf is governed by our Data Processing Agreement, available at https://concessa.itsm-ltd.com/legal/data-processing-agreement and incorporated into the End User Terms.

4.2 Where we act as a controller. We act as a controller in our own right for:

• support correspondence you send to us (section 5.4);
• licence and subscription records supplied to us by Atlassian (section 5.5); and
• business contact records relating to your organisation.

5. Personal data we process

5.1 Atlassian account identifiers and display names

The App handles Atlassian account IDs (AAIDs) — opaque identifiers assigned by Atlassian — in order to attribute App records to the correct user, apply permissions and render user references in the App’s interface.

It also stores display names alongside the account ID in certain records: the actor on an audit entry, an approval’s approver, a CAB meeting’s attendees and a CAB action’s owner. This is deliberate. A governance record has to remain readable years later, to an auditor who was not there, after the people named in it have left; a record that resolves to an opaque identifier and nothing else fails at the only moment it matters. Everywhere else, the App holds the account ID alone and asks Jira for the name when it needs to show one.

The App reads no email address and no avatar. It calls no Atlassian endpoint from which it takes either, and stores neither.

One consequence worth stating plainly: the App can hold an account ID and display name for somebody who has never opened it. A CAB meeting attendee, or the owner of an action arising from a meeting, is recorded because a colleague named them. Their rights are exactly the same as anyone else’s — see section 12.

5.2 Content held in your Jira site

To perform its function, the App reads a defined set of Jira data: an issue’s summary, status, issue type, project, assignee, reporter and creation date, the dates in Jira Service Management’s change-management date fields where your site has them, and whether the issue is a Jira Service Management customer request; a project’s name, type and issue types; the names and types of your site’s fields, to find those date fields and the request-type field; the caller’s project permissions; and project role membership. That content may contain personal data if your users have entered personal data into it. Each day, the App also checks the issues behind a limited number of its change records for the status property described in section 7, working through every project set up in Concessa, whether or not that project publishes, so that it can keep the property current where publishing is on and remove it where publishing is off. It uses only the time recorded in the property.

The App writes to Jira in two ways. The first is always on: a plain-text comment on a change issue, posted under the name of the person who acted, when an approval is requested, granted, rejected or rescinded, and when a change has been reviewed at a CAB meeting. On a Jira Service Management project that comment is an internal comment, the kind Jira Service Management keeps off its customer portal; an issue there that is not a customer request gets an ordinary comment instead, because no portal shows that issue. The comment is posted after the action it reports has been saved: if Jira refuses it, the action still stands, and the App tells the person the comment was not posted. The second is off unless a project administrator switches it on: a small set of status values written onto each change’s Jira issue as an issue property — a small record Jira keeps with the issue, which Jira search can read — so that changes can be found with Jira search. The App writes and removes that property with its own permissions rather than the acting user’s, and what it writes holds no names, no account identifiers and no free text; section 7 describes it. The App creates no issues, edits no fields and changes nothing in your Jira configuration. Installing it does add six Concessa field names and one Concessa function to Jira’s search language, across your whole site.

All of this content remains within your Atlassian site at all times; it is not copied to us.

5.3 The App’s own governance records

The App stores its own records in Forge hosted storage, scoped to your installation: change records, approvals, freeze windows, CAB meetings and actions, an append-only audit trail, and each project’s configuration. These reference individual users by account ID, and in the cases listed in section 5.1 by display name, and they contain free text your users type — approval comments, change summaries, a post-implementation review’s lesson, the reasons given for revising a recorded outcome or correcting a review, freeze window names and reasons, the reason given for overriding a freeze, CAB agenda items, the project’s standing CAB agenda template, the reason a meeting was cancelled and action descriptions — which may contain personal data if your users put it there.

Annex 1 of the Data Processing Agreement lists every field of this kind, exhaustively, and clause 9.4 of that agreement explains which of them are carried into the audit trail’s hash chain and therefore cannot be erased without breaking it.

5.4 Support correspondence

This is the one category of data that reaches our own systems. When you contact support@itsm-ltd.com, we receive and process your name, email address, employer or Atlassian site details, and whatever information you choose to include in your message — including any screenshots, log extracts or exported data you attach. Please do not send us personal data, credentials or confidential content that is not necessary to diagnose your issue.

5.5 Licence and billing records

Where the App is licensed through the Atlassian Marketplace, Atlassian supplies us with licence records including the Support Entitlement Number (SEN), the licensed tier, the licence status and dates, the customer organisation name and a technical or billing contact. Atlassian is the merchant of record for such transactions; we do not receive or process payment card data.

5.6 Platform logs

The Forge platform generates operational logs for the App’s functions. These logs are produced and retained by Atlassian under Atlassian’s own retention arrangements, and we can read them for our own App through the Forge developer console.

The App writes log statements in one area only: publishing to Jira and its search function. Those lines exist so that we can tell a publication that failed, or a search the App refused to answer, from one that simply had nothing to do. They carry issue identifiers, project keys, counts, HTTP status codes from Jira and error text, and they are built to carry no account ID and no display name. The App’s daily reconciliation — its one scheduled task, which brings published status back in line with the App’s records and removes it where publishing has been switched off — writes one line of counts every day, whether or not any project publishes. The search function’s lines can also record text the person searching typed: when the function refuses to answer, the project key it was given; and when it cannot find its argument at all, the first 200 characters of the request Jira sent it. A further caveat for completeness: where a call to Jira fails, the error the platform records includes a fragment of Jira’s own response, which could include issue content.

5.7 Analytics — there are none

The App contains no analytics. There is no usage counter, no telemetry, no third-party tracker and no store in which usage statistics could be accumulated. We have built nothing to tell us which features you use. The nearest thing is the logging in section 5.6: it would show us whether an installation publishes to Jira, how many change records its daily reconciliation examined, published or removed, and when the App’s search function was used.

6. Purposes and lawful bases

We do not carry out automated decision-making producing legal or similarly significant effects, and we do not profile individuals. We do not knowingly process special category data; if your use of the App involves special category data within your Atlassian content, you remain the controller of that data and are responsible for identifying an Article 9 condition.

7. Where your data is stored

Data stored by the App resides in Forge hosted storage and inherits the data residency configuration of the Atlassian product it is installed alongside. Where you have pinned your Jira data to a particular Atlassian region, in-scope App data is pinned to that region, and Atlassian migrates it with your product data if you move regions. Data residency for Forge apps is managed by Atlassian; details and the current list of supported regions are published at Atlassian’s data residency pages.

Where a project administrator has switched it on, the App also writes a small set of status values onto each change’s Jira issue, as a Jira issue property named com.itsm-ltd.concessa.state. That property is stored by Jira, inside your own Atlassian site, alongside the issue it describes, and is subject to whatever data residency arrangements Atlassian applies to your Jira data. It is your Jira data rather than App data in Forge storage. The App has no way to restrict who reads it: assume that anyone who can read the issue, and any other app installed on your site, can read it. What the App writes into it is the change’s governance status, risk level and change type, the dates of its planned window, the number of approvals outstanding, the time the change record was last updated and a format version number — no names, no account identifiers and no free text.

Support correspondence (5.4) and licence records (5.5) are held in Google Workspace, in Ireland. We operate no support portal, no ticketing system and no hosting of our own; support is conducted by email.

8. Sharing and sub-processors

We do not sell personal data, and we do not share it for advertising or marketing purposes.

There are two, and one of them is Atlassian — the platform you are already running. We use no other processor: no support portal, no ticketing system, no analytics service, no error tracker and no hosting of our own.

We will give 30 days’ notice of any change to this list by updating this policy and the effective date. We may also disclose personal data where required by law, court order or a regulator, or to establish, exercise or defend legal claims.

9. International transfers

Because App data is held within Atlassian’s infrastructure, transfers are governed by Atlassian’s arrangements, including its Data Processing Addendum and the Standard Contractual Clauses with the UK International Data Transfer Addendum where applicable. Where we transfer support or licence data outside the United Kingdom, we rely on UK adequacy regulations or, where no adequacy decision applies, the International Data Transfer Agreement or the Addendum to the EU Standard Contractual Clauses. A copy of the relevant safeguards is available on request.

10. Retention

Published status values. Once publishing is switched off for a project, the App’s daily reconciliation removes the status values it wrote there. It examines a limited number of change records each day across every project set up in Concessa, so on a site with thousands of change records it can take weeks to reach them all. A project administrator can instead remove them straight away, without waiting for the reconciliation, with the Remove published data button on the project’s Concessa settings page. Neither route reaches an issue the App no longer holds a change record for. The App cannot remove anything once it has been uninstalled, so before you uninstall, switch publishing off and press Remove published data in each project that has published. Section 3.6 of the Cloud Security Statement has the detail.

App data in Forge hosted storage is retained for the life of the installation and is not aged out. Audit entries in particular are append-only: they are never edited or deleted while the App is installed, because a trail whose entries can disappear is not a trail. Section 12 explains what this means for erasure.

11. Security

App data is encrypted in transit and at rest by the Atlassian platform, is isolated per tenant, and is accessible to the App only through the minimum permissions it declares. Our security measures are described in full in the Cloud Security Statement at https://concessa.itsm-ltd.com/legal/cloud-security-statement, which is the authoritative account of them. Where we act as your processor, the same measures are set out as technical and organisational measures in Annex 2 of the Data Processing Agreement.

Where a security incident affects personal data we hold or process, we will notify the technical contact on your licence without undue delay and in any event within 72 hours of becoming aware, and will assist you in meeting your own regulatory notification obligations. Incident handling is described in section 8 of the Cloud Security Statement.

We are not ourselves certified to SOC 2, ISO/IEC 27001 or comparable standards. The Atlassian infrastructure on which the App runs is independently certified; those certifications belong to Atlassian and may be verified at the Atlassian Trust Center.

12. Your rights

Where we act as a controller (support correspondence, licence records), you have the right under UK GDPR to:

• request access to your personal data;
• request rectification of inaccurate data;
• request erasure, where a ground applies;
• request restriction of processing;
• object to processing carried out on the basis of legitimate interests;
• request portability of data you provided to us; and
• withdraw consent, where processing is based on consent, without affecting prior processing.

To exercise a right, email support@itsm-ltd.com. We will respond within one month, extendable by two further months for complex requests, and we will tell you if an extension applies. There is normally no charge.

Where we act as a processor (data inside your Atlassian site), please direct your request to the Atlassian customer whose site holds the data — normally your own organisation’s administrator. We will assist that customer in responding.

One limit on erasure, which you should know about before you buy. The App’s audit trail is hash-chained: each entry carries a hash of the one before it, so removing or altering an entry breaks verification for every entry after it. That is what makes the trail evidence. Some fields can still be redacted cleanly, because they are not carried into the chain — a CAB agenda item’s text, a CAB action’s description, a CAB attendee’s display name. Others are chained, including approval comments, change summaries, post-implementation review lessons, the reasons given for revising a recorded outcome or correcting a review, freeze window names and reasons, a freeze override’s reason, a meeting’s cancellation reason, the CAB standing agenda template, and the account identifiers recorded as actor attributions. Erasing one of those breaks the chain from that point forward, and the only alternative is to uninstall the App, which removes the record for every project on your site. Clause 9.4 of the Data Processing Agreement sets out the position in full, and the decision is one we take with the controller rather than for them.

Complaints. If you are dissatisfied with how we have handled your personal data, please tell us first at support@itsm-ltd.com; we operate a complaints procedure and will acknowledge your complaint within 5 business days and respond substantively within 30 days. You also have the right to complain to the Information Commissioner’s Office at ico.org.uk/make-a-complaint, by telephone on 0303 123 1113, or by post to Information Commissioner’s Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF.

13. Notice to residents of California

If you are a California resident, you have rights under the California Consumer Privacy Act as amended, including rights to know, delete, correct and opt out. We do not sell or share personal information as those terms are defined under the CCPA/CPRA, and we do not process personal information for cross-context behavioural advertising. We do not use or disclose sensitive personal information for purposes requiring an opt-out. To exercise a right, contact support@itsm-ltd.com; we will not discriminate against you for doing so.

14. Children

The App is a business tool licensed to organisations and is not directed at children. We do not knowingly process the personal data of anyone under 18 in connection with the App.

15. Changes to this policy

We may update this policy from time to time. Material changes will be notified by updating the effective date above and, where the change materially affects your rights, by email to the technical contact on your licence at least 30 days before the change takes effect. Previous versions are available on request.

---

This Privacy Policy is published in accordance with the Atlassian Marketplace Partner Agreement. It should be read alongside the End User Terms, the Cloud Security Statement and the Support and Maintenance Description for Concessa.