Action plan

What the screen is for#

The action plan lists the tasks the assessment surfaced, most urgent first. Each task can have a Jira ticket, evidence (references, files, frozen Jira queries) and the help of an AI assistant. A task goes through four statuses: "To do", "In progress", "Implemented" and "Verified".

At the top, the "Readiness" block gives the overall and per-framework percentage, and the number of tasks "Verified", "En cours" and "À faire".

Who can do what#

Step by step#

Find a task#

1. Use "Show", "Priority" ("Critical", "High", "Medium", "Low"), "Framework", or the filters "Late" and "Evidence to renew". "Reset" clears them.
2. Sort by clicking a column header: "Task", "Priority", "Status", "Due date", "Evidence".
3. Click "Detail" to open a task: "Description", "How to do it", "Linked requirements".

Change a task's status#

1. Choose the new status in the row's list.
2. The screen shows "Saving…" then "Saved".
3. If the task has a Jira ticket, its status follows (see below).

Jira tickets#

1. In the "Jira tickets" block, check the project ("Projet : SEC"). If it is missing, click "Choose a project", then "Save". To change it, click "Change project".
2. Click "Create the N tickets" (or "Create the Jira ticket"). The app creates up to 8 tickets at a time, one task = one ticket. If some remain, run it again: nothing is created twice.
3. If the screen says tickets are being created elsewhere, wait two minutes before running it again.
4. Click a ticket key to open it in Jira.

Two-way synchronisation.

• From the app to Jira: a task's status changes its ticket's status (To Do, In Progress, Done). The app uses your Jira identity. If your transition right or the ticket's workflow forbids it, the screen says "The status is saved, but the Jira ticket could not follow". When a workflow rule refuses the closure (for example "no closing without evidence", see below), the screen says so and gives the way forward: "Jira refused the closing: a workflow rule (for example “no closing without evidence”) prevents it. Add evidence, then change the status of the task and set it back to “Verified”." The task status stays saved; the ticket stays where it was.
• From Jira to the app: moving a ticket to "In Progress" or "Done" in Jira advances its task. "Done" gives "Mise en œuvre": verification is always done in the app. The screen shows "Changed in Jira" with the person and the date.
• If a ticket of a verified task is reopened in Jira, the task stays verified and the screen shows "Ticket reopened in Jira".
• Tickets already created stay in their original project when you change project.

Inside Jira itself: the ticket panel, the gadget and the closure rule#

• The ticket panel. On a ticket created by the app, the "•••" menu of the ticket view offers "NexusGRC Compliance". The panel shows the task's status, its requirements with their codes (ISO 27001, SOC 2), its Annex A controls, the number of evidence items with the most recent ones (name, type, date), and a warning if it has none. It is read-only: evidence is added in the app, which the "Open in NexusGRC Compliance" button opens. On any other ticket, it says the ticket is not about compliance. Jira shows this panel only in the new ticket view, and its button only to people who can edit the ticket.
• The dashboard gadget. "NexusGRC Compliance" can be added to a Jira dashboard. It reuses the figures of the "Tableau de bord" tab: readiness per framework, late tasks, evidence to renew. It has no setting.
• The "no closing without evidence" rule. A Jira administrator adds it as a validator on the transition of their choice (for example to "Done"). It refuses the transition of an app task that has no evidence (file, reference or frozen Jira query), with a message that says what to do; any other ticket passes. If the app cannot answer (outage, response too slow), or if the ticket has just been moved to another project, the transition is accepted: blocking a team's workflows because of an outage costs more than an unverified closure, and the latter already shows in the dashboard and in the audit pack. Without an active licence, the app is read-only and refuses to add evidence: the rule then accepts the transition, otherwise nothing would unblock the ticket. Jira only provides the licence to paid apps in production; in development or for a free app, the rule always applies. By default, Jira only offers this type of rule in company-managed projects.

Add evidence#

In the task's "Detail", "Preuves" block:

1. Choose the "Type": "Document", "Link", "Screenshot", "Report", "Attestation", "Ticket" or "Other".
2. Give a "Name of the evidence" (a document title, a ticket key, a page name).
3. Optionally enter an "Address (optional)" in https://, with no space or credentials.
4. Or attach a file ("Joindre un fichier (facultatif)", Attach a file, optional): 25 MB at most, as PDF, image, Word, Excel, PowerPoint, CSV, text or ZIP. A file or an address, not both.
5. Click "Add the evidence". Evidence cannot be removed yet, and a task carries 100 at most.

To retrieve a file, click "Download". See also Evidence.

Freeze a Jira query#

A Jira query can serve as evidence: the list of tickets it selects is frozen at a date, with a fingerprint. In the "Detail", "Jira queries" block:

1. In "Add a Jira query", enter the "JQL query".
2. Enter the period ("Du", "Au"), which applies to the tickets' creation date. You can ask for it to be redone every N days.
3. Click "Preview": the app counts the tickets and shows the first ten, with the "Query run".
4. Click "Add the query". A task carries 20 queries at most.
5. Click "Freeze now": the app records the ticket keys (1,000 at most), their count and a fingerprint. The result can be "complete" or "partial" if the list was truncated.
6. The badge says "Up to date", "To redo" or "Never frozen". When you close a task that has an unfrozen or to-redo query, the screen reminds you.

The query runs with your Jira rights: you only freeze what you can see. The app keeps no ticket title or status, only the keys, the count and the fingerprint.

Freeze Jira Service Management evidence (Advanced edition)#

Two pieces of evidence that ISO 27001 auditors ask for come from Jira Service Management. They are prepared in the same "Add a Jira query" form: the "Type of query" field offers "Free query", "Approved changes" and "Resolved incidents".

1. Choose "Approved changes" or "Resolved incidents".
2. Choose the "Service desk". For incidents, tick the "Request types that count as incidents" (20 at most).
3. Enter the period. It applies to the requests' resolution date (not their creation date, as for a free query).
4. Click "Preview", then "Add the query", then "Figer maintenant". The app builds the JQL query and has Jira validate it; "Query run" shows it.

The freeze keeps 100 requests at most per evidence, with their approvals (decision, date, approver identifiers; names are looked up when shown) and, for incidents, the creation and resolution dates. Beyond 100, the evidence says so ("partial: the first 100 requests out of N") instead of cutting silently. "View the N frozen requests" opens the table. The fingerprint is calculated like that of the other frozen queries.

Good to know:

• The presets appear only if you can see at least one JSM service desk on the site; otherwise the screen says why. If JSM refuses to read a service desk or a request, nothing is frozen.
• In the Standard edition, choosing a preset carries the "Édition Advanced" label instead of failing, and the "Requête libre" stays allowed. A JSM snapshot that was already frozen stays readable and exportable: the action is blocked, not the data.
• The audit pack keeps one line per snapshot (query, period, count, fingerprint): it does not yet carry each request or its approvals.

The AI assistant#

In the task's "Detail", "Assistant" block (labelled "Édition Advanced", Advanced edition):

1. Click "Explain this task" or "Suggest evidence".
2. The answer is marked "Generated by AI, to review". Review it: it is neither stored nor applied.
3. If the AI cannot answer, you get a "Standard answer", with the reason: edition not included, month's budget reached, or error.

See what the AI sees.

What the auditor will take from it#

• A dated plan, with an owner, a status and a due date per task.
• Evidence attached to each requirement, with its author and date.
• Frozen Jira queries, verifiable by their fingerprint (including, in the Advanced edition, the approved changes and the resolved incidents of Jira Service Management).
• Every status change is in the audit log.

Known limits#

• A ticket deleted in Jira leaves a dead link. The app flags it but does not yet allow detaching it.
• A ticket transition that requires a mandatory field fails.
• If Jira search is blind for more than two minutes after an interrupted creation, a second ticket can be created.
• No ticket yet for a task that has been set aside.
• The ticket panel is read-only and does not open the task itself: its button opens the app, where you find the task.
• Evidence cannot be removed; an evidence file cannot be deleted.
• The JSM presets freeze 100 requests per evidence at most, and their detail is not in the audit pack.
• The assistant answers only if the Advanced edition is active and within the monthly budget.