Security and privacy

It describes what the app does, and promises nothing more.

Where is my data stored?#

The app runs on Atlassian Forge. It has no server of its own, no remote service, and no webtrigger module: it is designed to meet the conditions of the "Runs on Atlassian" programme, which Atlassian alone assesses.

• Forge SQL. The app's database, one per installation. It holds the Statement of Applicability, assessment answers, tasks, evidence references, frozen Jira queries (for a JSM preset: 100 requests at most, with their approvals), risks, assets, audits, access reviews, monitoring results, the audit log, the role grants and the custom roles. It also keeps policies, incidents, AI systems, vendors, people and the management-system registers, and the "How we implement it" text of each control and, for each person who used the assistant, their account identifier with the month's token count. For an object read from JSM Assets, the app keeps only its identifier, key, name, type and the date it was read, plus the owner if you named the attribute that holds it. It does not copy the other attributes. The data is classified as "user-generated content" (justifications, notes), "personal data" (Atlassian account identifiers of managers, approvers, reviewers) and "other" (states, dates).
• Forge object storage. The evidence files you attach (25 MB at most per file). They only go through the app. When this page was written, Atlassian presented object storage as a preview feature: see its documentation for its current status.
• Jira. The tickets the app creates in your project, with a property and labels that link each ticket to its task.
• Residency. The app uses no host other than Atlassian and has no remotes, no providers and no permissions.external. Where Atlassian hosts Forge SQL and object storage for your site, and what happens to that data if the site changes region, are Atlassian's commitments: check them in its data residency documentation, we do not guarantee them here. One exception to note: the request to the AI model used by the assistant (Advanced edition) goes through Forge LLMs, whose residency we have not verified.

Which identity does the app use to talk to Jira?#

By default, yours (asUser): Jira then applies your permissions and the app sees only what you see.

The app's identity sees every project it has access to. For that reason, its reads are limited to the projects you chose in the monitoring settings and to the tickets the app created itself, and it keeps only counts.

Objects read from JSM Assets are shown only to people who can edit risks and assets (administrators, compliance managers, risk and asset managers); everyone else sees the app's light register alone. An e-mail reminder carries only the task title, its due date or the date of the evidence, and a link to the app.

What does the AI model see?#

The assistant (Advanced edition) relies on Forge LLMs, an Atlassian service. No call goes to any other provider. It has twelve functions, listed with their rights in AI assistant; the full table of what is sent, with the size limits, is there too. In short, the model receives, depending on the function you run:

• A task ("Explain this task", "Suggest evidence"): its title, its description, its implementation guide, a short evidence hint written by us, the requirements it covers (framework, code, title), its status, its priority and its review cycle.
• A policy: the text of the section you are working on ("Ask for a proposal", "Suggest a flowchart"), or the whole text of the policy ("Suggest controls"), or the text before and after of each changed section ("Summarise for the approver"), with the policy title and the list of catalog controls.
• A risk: the sentence you type, or the title and description of the risk, the installation's risk matrix, the assets (identifier and name) and the catalog controls (identifier and title).
• A control ("How we implement it"): its 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, the declared state and the current text.
• A row of the statement of applicability: 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 of the justification.
• A piece of evidence ("Review with the assistant"): what the control expects, its name (the file's original name), its type, the date it was added; for a frozen Jira query, the query, the period, the number of issues and the first ten issue keys.
• A failing test: the test name, its last result (status, reason code, measure), the date since when it fails, the titles of the controls it checks.

Removed or replaced before sending, for the ten most recent functions: e-mail addresses, web addresses, Atlassian account identifiers and @name mentions; the name of each person the object names (owner, approver, people assigned to tasks) and your own, replaced by their role. Limit: the cleaning knows only those people. The name of a third party that you write in a free text is sent as it is. The cleaning applies to all twelve functions, the two oldest ("Explain this task", "Suggest evidence") included.

Never sent: the content of an evidence file or piece (the model receives only its name, its type and its dates), the address of a file, the person who added it, e-mail addresses, the audit log, access reviews, people, vendors, incidents, AI systems.

A proposal is neither stored nor applied: it is for you to review, take in, then save with the screen's button. The log keeps the function, the object, the number of tokens and your decision, never the text sent or the text received.

Budget. By default, 750,000 tokens a month per installation, of which one person can use only 40%. The app's publisher sets it for all sites; no setting in the app changes it or switches the assistant off. Beyond it, you get a standard answer, with no AI.

Where the request is processed, and how long Atlassian keeps it, has not been verified for this app: see the Forge LLMs documentation.

Which scopes does the app request, and why?#

All version 1 scopes are declared from the start: adding more later would force every administrator to approve again. No "manage" scope is requested.

The scopes requested#

The chained log and its verification happen inside the app, with no particular scope.

Does the app send data outside Atlassian?#

No. The manifest declares no network egress (no remotes, no providers, no permissions.external). Calls go to Jira, Forge SQL, Forge object storage and Forge LLMs, all at Atlassian, plus Atlassian's personal data reporting API. The interface runs with Forge's default content security policy: no inline style or script. The app's own code loads no outside resource. One exception, which is not a call made by the app: the thumbnail of the dashboard gadget is a static image at https://academy.nexusgrc.net/icons/nexusgrc-compliance-192.png, on a website we operate, and the browser of the person who views the gadget requests it. The app sends nothing to it.

The report and workbook of the audit pack are built in your browser, with no script or outside resource. The same goes for the Word and PDF files of policies and for reading the Excel workbooks of the import: they are made and read in your browser, and go through no outside server.

The chained log, and how to verify it#

Each significant change (assessment, status, evidence, approval, risk, audit, access review, setting) is written to the log with the actor, the date and a fingerprint that depends on the previous entry. Modifying, removing, adding or reordering an entry breaks the chain.

To verify: "Audit log" page, "Verify the integrity". The result is "Log intact" or "Log tampered at entry no. N". Details are in Audit log. Reviewers' free-text comments are not written to the log.

The log can be read by administrators (Jira administrators included), compliance managers and, for the length of their grant, auditors. Other roles do not read it.

Deletion and export of data#

The detail is in the French note data lifecycle. In short:

• Uninstallation. Data hosted by Forge (Forge SQL, object storage) is first "soft-deleted", then destroyed at the end of Atlassian's retention period: 28 days after uninstallation according to Forge's storage page, 60 days according to its lifecycle page (two Atlassian pages, two figures: the exact period is not settled). Reinstalling restores nothing automatically. Tickets created in Jira stay with you, with their nexusgrc property and labels.
• Closed Atlassian accounts. The daily run reports account identifiers to Atlassian's personal data API. For a closed account, the app removes its roles and replaces the cached name with "Closed account". The audit log is not rewritten (its fingerprint chain would no longer verify): the identifier stays, but screens and exports show "Compte fermé" instead of the name.
• Export (right of access). The "Your data" block of the Audit pack page provides a zip (CSV files, settings, fingerprint manifest). It is open to all editions, including with an inactive licence, to auditors, compliance managers and administrators. Evidence files are not in the zip: they are downloaded in the app. The complete audit pack remains reserved for the Advanced edition.

Reporting a vulnerability#

Do not publish anything and do not open a public ticket. Write privately to the address given on the Support page, putting "SECURITY" in the subject.