NexusGRC · Legal document
Privacy policy: NexusGRC Compliance for Jira
Last updated : November 1, 2026
1. Who we are
The app is published by Abdelilah Cherkaoui, an individual based in Morocco ("we"), identified in the legal notice of the terms of use. Privacy contact: contact@nexusgrc.net. We have not appointed a data protection officer, which the GDPR does not require for this processing (Art. 37); the same address handles every data protection request.
Our roles.
- For the content and the personal data that you and your users enter in the app (the "Customer data"), your organisation is the controller and we act as your processor, under the data processing agreement. The Customer data sits in the Forge storage of your Atlassian site, not on a server of ours.
- For the few things we handle for our own purposes (section 5, rows 4 to 7), we are the controller.
2. What the app stores, and where
The app runs on Atlassian Forge and has no server of ours. It keeps data in three places.
| Where | What |
|---|---|
| Forge SQL, one database per installation | Statement of Applicability, assessment answers, tasks, evidence references, risks, audits, access reviews, monitoring results, the audit log, the list of compliance managers, settings; the management-system registers, policies and their acknowledgements, people and training records, vendors, incidents, AI systems and their impact assessments; the AI usage counters (see below). Two small tables serve speed: a read cache (copies of answers already computed for five screens, one day at most, never the names of people) and a resume point for the check of the audit log (position, fingerprint, date) |
| Forge object storage | The evidence files you attach, 25 MB at most per file |
| Jira (your site) | The tickets the app creates, with a nexusgrc entity property and the labels nexusgrc, nxg-task-... and control:... |
The data is declared to Forge in three classes: user-generated content, personal data, other.
Free text (justifications, notes, task descriptions) and evidence files may contain personal data if your users put some there. The app does not read the content of an uploaded file. Please do not enter personal data that the purpose does not need, and in particular no special categories of data (for example health data or human-resources files) unless you must: the app does not read uploaded files and has no antivirus.
Personal data the app holds
| Data | Detail |
|---|---|
| Atlassian account identifiers | Opaque identifiers (pseudonyms), no name and no e-mail address. They identify: holders of a role and who granted it; approvers of a statement; owners of a control or a task; authors of evidence; people who uploaded a file; authors of a frozen Jira query and of a snapshot; authors of a setting change; actors in the audit log; reviewers, auditors, owners and acceptors of risks, access reviews and internal audits; owners of corrective actions; accounts named in frozen Jira Service Management snapshots; authors of a ticket or action that comes from Jira. The daily run also keeps a list of these identifiers, with three dates per account and closed accounts included, to report them to Atlassian |
| AI usage counters | For each person who used the AI assistant: their Atlassian account identifier and the number of tokens used (one line per person and per month; during a trial, one line for the whole trial). One line per installation for the installation's own budget. No text sent or received. The person's lines are part of the daily report described in section 6 and are deleted when that account is closed; all lines are deleted when the app is uninstalled |
| Cached display name | One per access-review item: the name read from the Jira directory when the campaign was created |
| Names and e-mail addresses | Not stored. Other names are read again from the Jira directory each time a screen is shown and are not kept. An e-mail address is never stored |
| Reminder log | Task identifier, type of reminder and date of the last send. No account, no address, no ticket key, no title. Jira sends the message; the app keeps neither the account nor the address |
Which identity the app uses in Jira. For what a person asks, the app calls Jira as that person, so Jira applies that person's rights. Some processing runs under the app's own identity: the daily run, the tickets created by monitoring or for audit findings, and the reaction to a status change or a deletion of an app ticket.
3. Where the data goes
- The manifest of the app declares no remote service, no external provider and no external permission. The app's calls go to Jira, Forge SQL, Forge object storage, Forge LLMs and Atlassian's personal data reporting API, all operated by Atlassian.
- Forge SQL and Forge object storage are compatible with Atlassian data residency: the data stays where your Jira is and moves with it if an administrator moves it. Atlassian states that Forge aims to run the app's functions in the same location as your Jira, and may sometimes run one elsewhere for reliability or security.
- Two points are stated precisely because they are exceptions or are not established.
- The AI assistant (Advanced edition): see section 4. Its requests go to Forge LLMs, a service of Atlassian.
- The dashboard gadget thumbnail: Jira requires an absolute address for the thumbnail of a gadget. Ours is
https://academy.nexusgrc.net/icons/nexusgrc-compliance-192.png, a static image served by a website we operate and that is hosted on Vercel. The app does not load this image and sends nothing to it. The browser of the person who views the gadget requests it, as for any image on the web, so the server that serves it can receive the usual technical data of an image request (for example the IP address, the browser type and, depending on the browser's referrer policy, the address of the page that shows it). Vercel Inc. (United States), which hosts that website, acts as our processor for this request and keeps its technical request logs for a short period under its own terms. We do not use them to identify anyone and do not combine them with other data.
4. The AI assistant (Advanced edition only)
The assistant drafts and reviews; it proposes and the user decides. Outside the Advanced edition, and without an active licence, the app makes no call to the model.
Which model, which functions
- The assistant uses Forge LLMs, a service of Atlassian; the app calls no other AI provider. The manifest asks for a model of the Claude family.
- It has 12 functions: explain a task and suggest evidence; write, complete, shorten, make more formal or adapt a policy section, suggest the controls a policy supports, summarise what changed for an approver, suggest a flowchart; draft and assess a risk; draft the implementation text of a control; draft a justification in the Statement of Applicability; review a piece of evidence; explain a failing test.
- For every function the app first reads the object again with the rights of the person who asks. If that person cannot read or edit it, nothing is sent.
What is sent to the model
| Function | Sent |
|---|---|
| Explain a task, suggest evidence | The task's title, description and implementation guide, a short evidence hint written by us, the requirements it covers (framework, code, title), its status, priority and review cycle |
| Policy section, flowchart | The policy title and language, the title and text of the section as it is in the editor (20,000 characters at most), the action chosen, the names of the active frameworks; for a flowchart, also the role names read in the saved policy |
| Suggest controls for a policy | The policy title, the whole text of the policy and the catalog of controls (identifier and title) |
| What changed in a policy | The policy title and, for each changed section (30 at most), its text before and after |
| Draft or assess a risk | The sentence typed by the user, or the title and description of the risk; the risk matrix and appetite; the assets (identifier and name) and the catalog controls (identifier and title) |
| Implementation of a control | The control's title and description, the requirements it covers, the name and type of the attached evidence, the title and status of its tasks, the answers to the assessment with their notes (300 characters each), the declared state and the current text |
| Justification in the Statement of Applicability | The code and title of the requirement, the framework, applicable or not, the description of the control, the title and state of the controls that cover it, the current text |
| Review a piece of evidence | What the control expects; the name, type and date of the evidence; for a frozen Jira query, the text of the query, the period, the number of issues and the first ten issue keys |
| Explain a failing test | The name and source type of the test, its last result (status, reason code, measure), the date since when it fails, the titles of the controls it checks |
The texts of these fields (titles, descriptions, notes, policy text, the sentence typed for a risk) are what your users typed.
What is not sent
- The content of any evidence file (the app has no network access that could read it, and does not open uploaded files), the address of a file, and the person who added it.
- The audit log, the access reviews, the register of people and training, the vendors, the incidents and the AI systems.
- The owner, the approver and the other people the object names: before sending, their name is replaced by their role ("the person in charge", "the person asking"). The fields that carry a person (owner, author, approver, address, display name) are removed from what is sent.
- E-mail addresses, Atlassian account identifiers,
@namementions and web addresses (Atlassian addresses included): the app removes them from the text before sending. This cleaning applies to all 12 functions.
A limit we state plainly
A name typed in free text can reach the model. The cleaning knows only the people that the object itself designates (owner, approver, people assigned to its tasks, the person asking). The name of a colleague, a customer or a third party written in a title, a description, a note or a policy text, including the title of an asset or a task that appears in a catalog, is not recognised and is sent as typed. A first or last name of fewer than four letters, alone, is not recognised either. If the Jira directory does not answer, the owner's name is not removed (the e-mail address, the account identifier and the web addresses still are). Our own internal test confirmed this limit. We have not set a wider filter, because it would damage common words. Please do not type the names of people in the fields that go to the model.
What the model can do, and what happens to the answer
- The text of the customer is given to the model as data, with the instruction not to follow any instruction found in it. The model has no tool and writes nothing: no record is saved, no ticket created, no status changed. The answer must have a precise shape; if it does not, or if the model fails or exceeds 20 seconds, the user gets a standard answer computed by the app, without a model. These protections are tested with a test double of the model; they have not been tested systematically against a live model.
- The answer is neither stored nor applied. The user reads it, takes it or not, and saves it with the screen's own button. The audit log keeps the function, the object, the number of tokens and the decision, never the text sent or received.
- The assistant never accepts a risk or approves anything.
Budget
- The publisher sets a token budget: 750,000 tokens a month by default, for each installation (calendar month, UTC). One person can use at most 40% of it. Customers cannot change it or switch the assistant off inside the app. If the publisher sets it to 0, the model is off for every installation.
- The 30-day trial opens a preview of 100,000 tokens for the whole trial, not per month; the 40% share applies to it too. Once used, the answer is standard and the screen says the trial is over.
- When the installation's budget or a person's share is used up, the answer is standard, without a model, until the 1st of the next month (UTC). There is no top-up.
- The usage counters are described in section 2 (they hold an account identifier and a number of tokens, no text).
What we do not know
Where Atlassian processes these requests, how long it keeps them, whether it uses them to train models, and which company runs the model inside its service: not established. We make no claim about them. See Atlassian's documentation of Forge LLMs and its list of sub-processors.
5. Why we process data, and on what legal basis
These are the legal bases we rely on or propose to rely on.
| # | Purpose | Data | Our role | Legal basis (GDPR) |
|---|---|---|---|---|
| 1 | Run the app for you: store and show your compliance records, create and follow Jira tickets, run the daily checks, send reminders through Jira, produce exports | Customer data | Processor | Your instructions (Art. 28); the controller's own basis is yours to decide |
| 2 | AI assistant (Advanced edition) | Texts sent to Forge LLMs (section 4); AI usage counters (section 2) | Processor | Same as row 1 |
| 3 | Report account identifiers to Atlassian (each account again once 7 days have passed since its last report), remove the roles of closed accounts and replace their cached names (section 6) | Opaque account identifiers | Processor | Your instructions; honouring erasure when an account is closed |
| 4 | Answer support requests | Contact details, content of the messages | Controller | Contract or legitimate interests (Art. 6(1)(b) or (f)) |
| 5 | Handle vulnerability reports and security incidents | Reporter's contact details, technical details | Controller | Legitimate interests in securing the app; legal obligations on breach notification |
| 6 | Check the license and edition, and manage the subscription | Licence information that Atlassian provides to us | Controller | Contract (Art. 6(1)(b)) |
| 7 | Serve the gadget thumbnail | Technical data of the image request (section 3) | Controller | Legitimate interests (Art. 6(1)(f)): showing the gadget, which Jira requires |
6. Retention
| Data | How long | Who deletes it |
|---|---|---|
| Audit log | No limit while the app is installed. It is never pruned or rewritten | Nobody; it disappears when the app is uninstalled |
| Frozen Jira query snapshots | No limit: they are evidence. A user cannot delete them | Uninstallation |
| Tasks, evidence and evidence files, risks, audits, access reviews, Statement of Applicability | No limit, until a user deletes the task, risk, audit or campaign | The user; uninstallation |
| Monitoring results | The latest 400 per monitor | The app |
| Files uploaded and never attached | 24 hours | The daily run |
| Reminder log | Rows older than 90 days are deleted | The daily run |
| Settings and roles | As long as they are set; the roles of a closed account are removed | The app, an administrator |
| AI usage counters | One line per month for the installation, one per person and month, one for a trial, no text. No limit while the app is installed. A person's lines are deleted when their account is closed (daily report) | Uninstallation |
| Account status (the daily run's list of account identifiers) | One account identifier and three dates per account, closed accounts included. No limit while the app is installed | Uninstallation |
| Support messages | 3 years after the last exchange | Us |
| Security reports and incident records | 5 years after the case is closed, to show how it was handled | Us |
After uninstallation. On uninstallation, Forge first deletes the app's data "softly"; Atlassian then destroys it at the end of the retention period of its Standard Data Retention and Disposal policy, which Atlassian documents in its SOC 2 report. If a reinstallation is requested within 21 days, Atlassian can relink it to the old data. Reinstalling restores nothing automatically. If a site is deleted, it is soft-deleted first and all app data is then deleted. The tickets the app created in Jira, with their property and labels, stay in your Jira.
7. Your rights
Under the GDPR you may have the right to access, rectify, erase, restrict, object to the processing of your personal data and to receive it in a portable form, and the right to complain to a supervisory authority: the data protection authority of your country (in the European Union, for example the CNIL in France). For the processing we carry out ourselves in Morocco, you may also contact the Commission nationale de contrôle de la protection des données à caractère personnel (CNDP).
- Customer data. Your organisation is the controller (section 1). Send your request to your organisation's Jira administrator or compliance manager. We assist them with such requests.
- What the app gives your organisation.
- Access and portability. The "Your data" block of the "Audit pack" page produces a zip: CSV files, settings and a manifest of SHA-256 fingerprints. It is open to all editions, including with an inactive license, to compliance managers and Jira administrators. Evidence files are not in the zip; they are downloaded in the app.
- Closed accounts. The daily run reports account identifiers to Atlassian. For an account Atlassian says is closed, the app removes its roles and replaces its cached name with "Compte fermé"; for an account whose data changed, it replaces the cached name with "Nom à actualiser".
- Deleting records. A user can delete a task, risk, audit or campaign.
- Limits you should know. The identifier of a closed account is not erased: it stays in the audit log and in other columns (task owner, uploader, creator) without time limit. The log is not rewritten, because its fingerprint chain would no longer verify; screens and exports show "Compte fermé" in place of the name. A user cannot delete frozen query snapshots. This retention serves the controller's need for an intact audit trail; the GDPR lets erasure give way where data is needed for compliance with a legal obligation or for the establishment, exercise or defence of legal claims (Art. 17(3)(b) and (e)). The identifier is a pseudonym and no name is kept with it. We will update this policy if the approach changes.
- No automated decisions. The AI assistant only proposes text that a person chooses to use or not. The app takes no decision based solely on automated processing that produces legal or similarly significant effects on a person (Art. 22).
- Data we control (section 5, rows 4 to 7): write to contact@nexusgrc.net.
8. Subprocessors and recipients
Atlassian is the only subprocessor of the app. It provides Jira, Forge SQL, Forge object storage and Forge LLMs. The list is on the subprocessors page.
For our own processing as controller (section 5, rows 4 to 7), the recipients are: Vercel Inc., which hosts the gadget thumbnail; our e-mail provider, for support messages and security reports; and Atlassian, for licence information.
9. International transfers
The app sends no data to a server of ours. Customer data is stored where your Jira is, under Atlassian data residency. Atlassian, the app's only subprocessor, belongs to a group with entities outside the European Economic Area. Transfers of personal data to Atlassian are governed by the Forge Data Processing Addendum, which incorporates the European Commission's standard contractual clauses, with provisions extending them to the United Kingdom and Switzerland. For requests to Forge LLMs, Atlassian does not state where they are processed, and we make no claim about it. The gadget thumbnail request (section 3) reaches Vercel Inc., in the United States, under Vercel's data processing addendum, which relies on the 2021 standard contractual clauses. We are based in Morocco, which the European Commission has not recognised as ensuring adequate protection. Personal data reaches us only when you write to us (support, security reports) and as the counts and codes of function logs; where a customer's personal data is transferred to us as its processor, the standard contractual clauses of the data processing agreement apply.
10. Security
The app's controls are described in our security documentation, available on request. In short:
- The audit log is chained by fingerprints, can be verified in the app, and is readable only by compliance managers and Jira administrators. We run no server that receives the data the app stores: only the app's code, running in Atlassian Forge, processes it. We see function logs, which hold counts, codes and the name of an error class only, and whatever you choose to send us for support. The one request that reaches a site we run is the gadget thumbnail (section 3).
- Known limit, still open. By default the access level of the app is "Reader", so any signed-in account of your Jira site can read the app's data and download evidence files, even with no role in the app, except the register of people, the audit log, the settings, the roles, the management system, the access-review campaigns and the objects read from JSM Assets. An administrator can choose "Contributor", so that each person reads only what is assigned to them. The AI assistant follows the same rights. It stays inside your site, and no leak between customers is known.
- Atlassian's Forge shared responsibility model makes Atlassian responsible for encrypting data at rest in Forge app storage, for encrypting all traffic with TLS (with HSTS) and for separating customers' storage. We rely on these platform measures and have not tested them ourselves.
- The app is not certified (no SOC 2, no ISO 27001) and has not had an external penetration test.
- To report a vulnerability, use contact@nexusgrc.net (a private channel; please do not put details in a public issue). Fix targets are on the support page.
11. Changes and contact
We will publish changes to this policy at https://www.nexusgrc.net/legal/jira-privacy and tell customers by updating the date shown at the top of this page. Contact: contact@nexusgrc.net. Legal notice: see the terms of use.