NexusGRC · Legal document
Data processing agreement: NexusGRC Compliance for Jira
Last updated : November 1, 2026
This data processing agreement (Article 28 of the GDPR) applies to the app "NexusGRC Compliance for Jira" (the "app"), which runs on Atlassian Forge. It does not cover the NexusGRC SaaS platform.
Parties
- Controller ("Customer"): the organisation that installs the app on its Atlassian site.
- Processor ("NexusGRC"): Abdelilah Cherkaoui, an individual based in Morocco, identified in the legal notice of the terms of use.
The data is stored on Atlassian infrastructure, in the Customer's Forge storage. We run no server that receives it. The code we publish runs in Atlassian Forge, and for what the Customer asks, it runs with that person's Jira rights. For the data the app holds for the Customer, the Customer is the controller and NexusGRC is its processor.
1. Subject matter, duration, nature and purpose
1.1 NexusGRC provides the app to the Customer. In doing so, the app processes personal data on the Customer's behalf, as described in Annex I.
1.2 The processing lasts as long as the app is installed on the Customer's site, plus the period in which Atlassian keeps and then destroys the data after uninstallation (section 9).
1.3 The purposes are to store and show the Customer's compliance records, create and follow Jira tickets, run daily checks, send reminders through Jira, produce exports and, in the Advanced edition, provide the AI assistant.
2. Instructions
2.1 NexusGRC processes the personal data only on the Customer's documented instructions, which are: these terms, the Customer's use of the app's functions, and the Customer's configuration of the app. 2.3 NexusGRC informs the Customer immediately if, in its opinion, an instruction infringes the GDPR or another data protection law. NexusGRC does not transfer personal data to a third country except on these instructions and as section 11 describes.
2.2 NexusGRC runs no server that receives the data the app stores; only the app's code, running in Atlassian Forge, processes it. NexusGRC sees function logs, which hold counts and codes only, and the information the Customer chooses to send for support (see the support page).
3. Personnel
The app is published by a sole operator, an individual. Only the publisher has access to the information NexusGRC receives for support. He is bound by a duty of confidentiality that survives the end of this agreement. Should another person be given access, NexusGRC will bind that person by a written confidentiality commitment beforehand and limit access to what that person needs.
4. Security of processing (Article 32)
NexusGRC applies the measures of Annex II. They describe the state of the app on the date shown at the top of this page, including the known limits. NexusGRC makes no availability commitment for the platform features that Atlassian offers in Preview (Annex II, row 17).
5. Subprocessors
5.1 The Customer gives a general authorisation for the subprocessors on the subprocessors page. Today that list contains Atlassian only, for Forge, Forge LLMs and the personal data reporting API.
5.2 NexusGRC will update the subprocessors page when it intends to add or replace a subprocessor. NexusGRC gives at least 30 days' notice before a new or replacement subprocessor starts processing Customer data, on that page and in the app's release notes. The Customer may object on reasonable data protection grounds within that period by writing to contact@nexusgrc.net. The parties then look for a solution in good faith; failing one, the Customer may stop using the app and uninstall it, and the processing of its data by the new subprocessor does not start.
5.3 Atlassian publishes its own terms, among them its Data Processing Addendum, its Forge Data Processing Addendum and its list of sub-processors. We do not restate them here. NexusGRC remains responsible for the subprocessor as the law provides.
6. Assistance with data subject requests
NexusGRC helps the Customer answer requests of data subjects, taking into account the nature of the processing. The app gives the Customer these means:
- Access and portability: the "Your data" block of the "Audit pack" page exports CSV files, settings and a manifest of SHA-256 fingerprints, in every edition, including with an inactive license, for compliance managers and Jira administrators. Evidence files are not in the export; they are downloaded in the app.
- Closed accounts: the daily run reports account identifiers to Atlassian, each account again once 7 days have passed since its last report, as the run's time allows; for a closed account the app removes the roles, deletes the person's AI usage counters and replaces the cached name with "Compte fermé". The AI usage counters (an account identifier and a number of tokens) are part of this report.
- Erasure of records: a user can delete a task, risk, audit or campaign.
- Limit: the identifier of a closed account remains in the audit log and in other columns without time limit, and a user cannot delete frozen query snapshots. This retention serves the Customer's need for an intact audit trail (Article 17(3)(b) and (e)); the identifier is a pseudonym and no name is kept with it. The privacy policy describes it, and we will update both texts if the approach changes.
A data subject who writes to NexusGRC about Customer data is referred to the Customer's organisation.
7. Personal data breach
7.1 NexusGRC notifies the Customer of a personal data breach without undue delay, and in any event within 48 hours after becoming aware of it, so that the Customer can meet its own 72-hour deadline (Article 33).
7.2 The notice describes, as far as known: the nature and period of the incident, the categories and approximate number of data subjects and records, the likely consequences, the measures taken or proposed, and a contact. NexusGRC gives what it knows and completes it afterwards.
7.3 NexusGRC notifies Atlassian of a security incident without delay and at the latest within 24 hours, with updates at least every 6 hours while the incident is being contained.
7.4 The incident runbook is written and has never been exercised. It is not a certified process.
8. Assistance with impact assessments and prior consultation
NexusGRC provides the information it holds about the app for the Customer's data protection impact assessment, and in particular the documents mentioned in section 10. The AI flow (section 1.3) has no established residency, retention or training position (see the privacy policy, section 4).
9. Deletion and return of data at the end of the services
9.1 Return. Before uninstalling, the Customer can export its data (section 6) and download its evidence files in the app.
9.2 Deletion. NexusGRC keeps no copy of the Customer data outside the Customer's Forge storage and Jira; the only other place where the app sends a part of it is Forge LLMs (section 1.3). 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 the site is deleted, it is soft-deleted first and all app data is then deleted.
9.3 What stays. The tickets the app created in Jira, with their nexusgrc property and labels, stay in the Customer's Jira.
9.4 An inactive license does not delete data. Routine clean-up continues: files uploaded and never attached, old reminder entries, and the roles of closed accounts.
10. Audits and information
10.1 NexusGRC makes available the information needed to show compliance with this agreement. The Customer, or an independent auditor bound by confidentiality that it appoints, may audit compliance with this agreement. The Customer first asks in writing for the information it needs; NexusGRC answers within 30 days. If that does not suffice, an audit may take place once a year, on 30 days' written notice, during business hours, at the Customer's expense, and in a way that does not give access to other customers' data or to Atlassian's systems, which Atlassian's own reports cover. A further audit may take place after a personal data breach or when a supervisory authority requires it.
10.2 The security documentation of the app covers the architecture and data classification, the data lifecycle, the security sheet, a pre-filled security questionnaire, the security review, the incident runbook and the threat model. It is written in French and available on request.
10.3 There is no SOC 2 or ISO 27001 report for the app and no external penetration test. The certifications of Atlassian cover its platform, not the app.
11. 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 (privacy policy, section 3) reaches Vercel Inc., in the United States, under Vercel's data processing addendum, which relies on the 2021 standard contractual clauses.
NexusGRC is based in Morocco, which has no adequacy decision. To the extent the Customer's personal data is transferred to NexusGRC (for example in a support request), the standard contractual clauses adopted by the European Commission in Decision (EU) 2021/914, Module Two (controller to processor), are incorporated into this agreement by reference, with the Customer as data exporter and NexusGRC as data importer; Annex I and Annex II of this agreement serve as their annexes; clause 7 (docking) does not apply; under clause 9, option 2 applies with the notice period of section 5.2; clauses 17 and 18 designate French law and the courts of France. If they conflict with this agreement, the clauses prevail.
12. Liability and governing law
Liability under this agreement follows the terms of use, section 11. Governing law and jurisdiction: this agreement is governed by Moroccan law and the court named in section 14 of the terms of use has jurisdiction, except for the standard contractual clauses of section 11, which follow their own clauses 17 and 18. If this agreement and the terms of use conflict on personal data, this agreement prevails.
Annex I. Description of the processing
| Item | Description |
|---|---|
| Subject matter | Providing the Jira app NexusGRC Compliance to the Customer |
| Nature | Storage, display, comparison, export, deletion; creation and update of Jira tickets; daily checks; reminders sent by Jira; for the Advanced edition, sending to Forge LLMs the text of the object a person asks the AI assistant about (12 functions, listed in section 4 of the privacy policy) |
| Purpose | Preparing for and tracking ISO 27001 and SOC 2 work, as the Customer decides (section 1.3) |
| Duration | As in section 1.2 |
| Categories of data subjects | People in the Customer's Jira site who hold a role in the app, approve a statement, own a control, task or risk, add evidence or upload files, review or audit, own a corrective action, are named in a frozen Jira Service Management snapshot, are recorded in the register of people and training, act in the log, use the AI assistant, or whose access is reviewed |
| Categories of personal data | Opaque Atlassian account identifiers (pseudonyms), including those of the owners of corrective actions, those named in frozen Jira Service Management snapshots, those kept in the account status table (one identifier and three dates per account, closed accounts included) and those kept in the AI usage counters (one identifier and a number of tokens per person and month); one cached display name per access-review item; free text and files that users enter. Never an e-mail address stored by the app |
| Special categories | The app is not designed to hold them. Free text and evidence files may contain whatever the Customer enters, and the app does not read the content of files |
| Retention | Audit log, frozen query snapshots, tasks, evidence, risks, audits, access reviews, Statement of Applicability, AI usage counters (no text), account status (one identifier and three dates per account): no limit while installed. Monitoring results: latest 400 per monitor. Unattached uploads: 24 hours. Reminder log: 90 days. After uninstallation: section 9 |
| Location | Same place as the host Jira, moving with it (Atlassian data residency). Forge aims to run functions in the same location and may sometimes run one elsewhere. Forge LLMs: location not stated by Atlassian |
Annex II. Technical and organisational measures
State on the date shown at the top of this page. "Not verified" means that the check described has not been made, not that the measure is absent.
| # | Area | Measure and state |
|---|---|---|
| 1 | Hosting | The app runs on Atlassian Forge, with no server of ours |
| 2 | Isolation between customers | One Forge SQL database and one object store per installation, separated by the platform. Never tried with two real sites |
| 3 | Encryption | Atlassian's Forge shared responsibility model makes Atlassian responsible for encrypting data at rest in Forge app storage and all traffic with TLS (with HSTS). The app adds no encryption of its own; we have not tested these platform measures |
| 4 | Network exits | None declared in the manifest: no remote service, no external provider, no external permission; a test checks it |
| 5 | Access control | Every request needs an authenticated Atlassian account; writes pass an authorisation check. Open limit: by default the access level of the app is "Reader", so reads are open to any authenticated account of the site, with or without a role, evidence files included, 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. No leak between customers is known |
| 6 | Least privilege towards Jira | For what a person asks, the app calls Jira as that person. Twelve scopes are declared, none of them "manage"; the list is on the Marketplace listing |
| 7 | Input handling | Requests are validated by strict schemas, database values are bound, uploads are limited to a closed list of file types and 25 MB with a SHA-256 fingerprint, and the app never opens them. Content is not read and there is no antivirus |
| 8 | Audit log | Each important change is written with the actor, the date and a fingerprint that depends on the previous entry; changing, removing or reordering an entry breaks the chain, which the app verifies |
| 9 | Logs | Function logs carry counts, codes and the name of the error class. A test fails if a log line holds a ticket key, account, name or project key |
| 10 | Data minimisation for AI | Only the text of the object the person asks about goes to the model, never the content of files, the audit log, the access reviews, the register of people, the vendors or the incidents; e-mail addresses, web addresses, account identifiers and mentions are removed, and the people the object names are replaced by their role. Limit: a name typed in free text is not recognised and is sent as typed. Token budget set by the publisher (750,000 a month by default for each installation, 40% at most for one person, 100,000 for a whole trial). Details: section 4 of the privacy policy |
| 11 | Retention and deletion | See Annex I and section 9; closed-account handling and its open limit are described in section 6 |
| 12 | Backup and continuity | The app makes no backup of its own; a restoration has not been tested; recovery objectives are not decided. Atlassian keeps a soft-deleted copy until the end of its retention period |
| 13 | Vulnerability handling | Fix targets follow Atlassian's policy: critical 10 days, high 4 weeks, medium 12 weeks, low 25 weeks, counted from report or triage; acknowledgement within 3 working days (see the support page) |
| 14 | Incident response | Runbook written, never exercised |
| 15 | Secure development | Continuous checks on changes (types, lint, tests, licences, dependency audit, static analysis); protection of the main branch and mandatory review are not enabled |
| 16 | Assurance | No SOC 2 or ISO 27001 certification of the app; no external penetration test |
| 17 | Platform features in Preview | Three Forge features the app uses are in Atlassian's Preview stage: the object storage that holds the evidence files, the workflow validator and the expression filter of the trigger that reacts to ticket changes. Atlassian may change or withdraw a Preview feature. The validator lets the transition through when the app cannot answer. No availability commitment is made for these features, evidence files included |
| 18 | Personnel | Sole operator bound by confidentiality; any further person bound in writing before access (section 3) |
Annex III. Subprocessors
See the subprocessors page.