This guide covers everything needed to operate the app day-to-day: privilege levels, every configuration field, the detection pipeline, the three-stage Article 23 workflow, the War Room dashboard, and how to manage update delays. For initial installation, see the Quick Start Guide.
Contents
The NIS2 Compliance Monitor automates your obligations under Directive (EU) 2022/2555, Article 23. When a cyber incident is detected in Jira it starts a three-stage legal reporting clock and guides your compliance team through each mandatory submission deadline.
Three legal deadlines from the Moment of Awareness (when the breach is confirmed):
These deadlines are mandated by EU law and are fixed — they cannot be configured.
There are two access levels in the app. Every action is checked on the server on every call — there is no session-based trust.
A user qualifies as an officer if they meet either condition:
| Action | NIS2 Officer | Everyone else |
|---|---|---|
| View compliance panel on any issue | ✅ | ✅ (read-only) |
| See breach status and countdown timer | ✅ | ✅ |
| Manually escalate an issue to breach | ✅ | ❌ |
| Fill in and save a draft report | ✅ | ❌ |
| Submit a stage (PDF + advance stage) | ✅ + must have Edit Issue on that specific issue | ❌ |
| Dismiss a review alert | ✅ | ❌ |
| View the War Room dashboard | ✅ | ❌ (UNAUTHORIZED screen) |
| Mark a stage complete from the dashboard | ✅ | ❌ |
| Open and save global configuration | ✅ | ❌ |
Note on stage completion: Stage submissions have a second permission check on top of officer status — the officer must also have Edit Issue permission on that specific Jira issue. This prevents an officer from advancing stages on issues in restricted projects they have no legitimate access to.
Note on War Room visibility: The War Room dashboard requires Officer or Admin status. Non-officers who navigate to Settings → Apps → NIS2 Compliance Center receive an UNAUTHORIZED screen — no breach data, issue keys, or deadline status is shown. This is enforced server-side on every request.
Permission results are cached per user for 5 minutes. If you add someone to the Officer Group, they may need to wait up to 5 minutes before the app recognises the change. The affected user can click 🔄 Refresh Permissions inside the compliance panel to force an immediate permission re-check, bypassing the cache.
Go to Jira Settings → Apps → NIS2 Compliance Center to open the admin panel.
These fields pre-fill the PDF report forms so officers don't retype them every time. They do not affect detection logic.
| Field | What it does |
|---|---|
| Organisation Name | Your company's legal name. Appears on all PDF compliance reports. |
| Organisation Sector | Your NIS2 classification (Energy, Health, Banking, etc.). Appears on reports. |
| Jurisdiction | Your EU member state regulator (e.g. Ireland NCSC, Germany BSI). Appears on reports. |
| Compliance Contact Name | The person regulators should contact. Pre-fills the report form. |
| Compliance Contact Email | Contact email for the same person. |
| Field | What it does |
|---|---|
| Keywords | Comma-separated terms scanned in issue summaries and descriptions. Only user-written text is
scanned — structural metadata is ignored. Example:
ransomware, data breach, leak, intrusion, exfiltration |
| Monitored Projects | Comma-separated Jira project keys (e.g. SEC, IT, OPS). Leave blank to monitor every
project. Case-insensitive. |
| Monitored Issue Types | Comma-separated issue types (default: Security, Incident). Leave blank to match all
types. |
| Trigger Priorities | A keyword match only triggers breach-level action if the issue priority is also on this list
(default: High, Highest, Critical, P1). Prevents routine keyword mentions in
low-priority tickets from triggering alerts. |
| Field | What it does |
|---|---|
| Auto-Escalate |
Off (default): Keyword + priority matches post a review comment and require an
officer to manually confirm the breach. On: Keyword + priority matches are immediately treated as confirmed breaches — the SLA clock starts automatically. Use only in environments where false positives are rare. |
| Low Priority Failsafe | On (default): If an issue has a matching keyword but its priority is not in the
Trigger Priorities list, the app silently adds nis2-review-required — no Jira comment,
no @mention. The issue surfaces in the War Room dashboard for passive officer review. This avoids
activity feed noise while still catching genuine incidents that were initially logged with the wrong
priority. Turn off if you want keyword matches below the trigger threshold to be completely
ignored. |
| Notification Target | The raw Atlassian Account ID of the person @mentioned in review-required comments. This is not an
email — it is the alphanumeric ID (e.g. 5b10ac2d... or a UUID). Find it in Jira user
management. Leave blank to post the comment without a mention. |
| Officer Group | The exact name of a Jira group whose members get NIS2 Officer privileges without needing full Jira Admin. The group must already exist in Jira. Case-sensitive. |
The app runs a background function on every Jira issue create and update event. No manual action is required.
updated timestamp to skip duplicate
webhook deliveries for the same event.statusCategory = done) and all
three NIS2 stages are complete, the app stamps nis2-compliant automatically.If the initial breach notification fails (e.g. a temporary Jira outage), a scheduled background job runs
every hour and retries any issue that has the nis2-breach label but not
nis2-notified. This ensures no breach goes unnotified even during platform disruption.
Open any Jira issue. The NIS2 panel appears in the right sidebar. What you see depends on the issue's state:
| Panel State | Meaning |
|---|---|
| ✅ NIS2 Monitoring Active | Issue is in scope but no breach or keyword match detected. |
| ✅ OUT OF COMPLIANCE SCOPE | Issue is outside your configured projects or issue types. |
| ⚠️ REVIEW REQUIRED | Keyword match detected. An officer must confirm or dismiss. |
| 🔴 BREACH DETECTED | Confirmed breach — three-stage countdown is running. |
| ✅ FULLY COMPLIANT | All three Article 23 stages submitted and filed. |
Two buttons appear:
nis2-dismissed and removes the review alert.
Use for false positives.A live countdown timer shows how long remains until the current stage deadline. The panel enters form mode.
Click Save & Preview Draft to save progress and review the report payload. Drafts are per-issue per-stage. If you are on Stage 2 and have no Stage 2 draft, the Stage 1 draft cascades in as a starting point so you don't retype shared fields.
Click 📎 Submit & Advance Stage. This:
nis2-stage{N}-complete.nis2-compliant and the issue is fully resolved.You can also click ⬇️ Download PDF Only without submitting — useful for previewing before filing.
About the internal audit records: Each stage submission generates a timestamped PDF attached to the Jira issue. These documents serve as your organisation's internal evidence that the Article 23 process was followed correctly. They are not submitted directly to your national competent authority — NCA submissions are made through each member state's own reporting portal. Your compliance officer should consult your NCA's guidance for the specific portal and format they require.
Mandatory fields: jurisdiction, organisation name, suspected malicious action, potential cross-border impact, impact details, incident type, detection date, compliance contact.
Inherits all Stage 1 fields. Additional mandatory fields: incident severity, indicators of compromise (IoCs), mitigation steps taken, affected services and systems.
Inherits all Stage 1 and 2 fields. Additional mandatory fields: root cause analysis, lessons learned.
Stage ordering is enforced. Stage 2 cannot be submitted until Stage 1 is complete. Stage 3 cannot be submitted until Stages 1 and 2 are both complete. Each stage generates a separately labelled PDF attached to the Jira issue.
The SLA clock starts from when the breach is first confirmed — either by the background handler on detection, or by an officer clicking 🚨 Confirm Security Breach. The original timestamp is stored and never overwritten. If the app retries a failed notification, the original detection time is preserved as the Moment of Awareness wherever possible.
Go to Jira Settings → Apps → NIS2 Compliance Center. The dashboard shows all active breach issues across all projects, sorted by urgency:
| Status | Sort order | Meaning |
|---|---|---|
| REVIEW | 1st | Keyword match detected — awaiting officer triage. Not yet a confirmed breach. |
| OVERDUE | 2nd | A stage deadline has passed without submission. Immediate escalation required. |
| PENDING | 3rd | Active breach — deadline still ahead, SLA clock running. |
| STAGE 1/2 DONE | 4th / 5th | Stage submitted, next stage in progress. |
| COMPLIANT | Last | All three Article 23 stages submitted — fully resolved. |
Load More fetches the next page of issues. Refresh (🔄) re-fetches all data from Jira — use this after submitting a stage to see the updated status.
Mark Stage N Done — advances the stage without generating a PDF from the browser. Use when a PDF has already been attached to the Jira issue separately.
| What changed | Delay | How to force immediately |
|---|---|---|
| Config saved (keywords, projects, etc.) | Up to 60 seconds — config is cached for 60s. | Wait 60s, or edit the issue to trigger a fresh webhook which re-reads config. |
| User added to / removed from Officer Group | Up to 5 minutes — auth results cached per user. | User clicks 🔄 in the compliance panel — forces a fresh permission check. |
| Issue breach status updated in Jira | Near-instant (seconds) via webhook. | Not needed. |
| Dashboard not showing new breach | Seconds — webhook lag. | Click 🔄 in the War Room dashboard. |
| Breach notification failed (Jira was down) | Up to 1 hour — hourly retry job. | Fully automatic — no action needed. |
The app caches configuration for 60 seconds to avoid repeated storage reads on every webhook. After saving new keywords or project scopes, existing in-flight webhook events may still use the old config for up to one minute. To trigger a fresh read on a specific issue, make any small edit to it (e.g. add a comment) — this fires a new webhook which will pick up the updated config.
The app uses standard Jira labels. You can use these in any JQL filter, board, or dashboard within Jira.
| Label | Meaning |
|---|---|
| nis2-breach | Confirmed NIS2 breach — SLA clock running. |
| nis2-notified | Breach alert comment posted to the issue. |
| nis2-review-required | Keyword match detected, awaiting officer review. |
| nis2-dismissed | Review alert dismissed as a false positive by an officer. |
| nis2-stage1-complete | 24h Early Warning submitted. |
| nis2-stage2-complete | 72h Full Notification submitted. |
| nis2-stage3-complete | 30-day Final Report submitted. |
| nis2-compliant | All three stages complete — fully compliant. |
Never manually remove nis2-breach or
nis2-notified from a live breach issue. The app uses these labels to guard against duplicate
processing. Removing them mid-breach can cause duplicate alerts or break SLA tracking.
Example JQL for your CISO board:
labels in (nis2-breach, nis2-review-required) ORDER BY created DESC
Open the compliance panel on the issue and click Dismiss False Alarm. This adds
nis2-dismissed and removes the nis2-review-required label. The issue will not be
flagged again unless a new update triggers the keyword check.
Open the compliance panel on the issue and click 🚨 Confirm Security Breach. This works even if the issue has no matching keywords or is outside the monitored scope.
The Moment of Awareness is set when the breach is first confirmed. If the initial notification failed and the hourly retry job ran instead, the timer may start from when the retry succeeded, with a warning logged. The timer cannot be edited manually — it is an immutable audit record.
Click 🔄 Refresh in the War Room. Submissions update Jira labels instantly, but the dashboard reads live data on refresh, not in real time.
After being added to the group, wait up to 5 minutes for the auth cache to expire, then try again. If it still fails, verify that the group name in the Officer Group field exactly matches the Jira group name (case-sensitive).
The background handler runs only on webhook events (issue created or updated). Existing issues are not retroactively re-scanned. To trigger detection on a specific issue, make a small edit to it — this fires a webhook and the new config will apply.
No. The app is built on Atlassian Forge. All processing happens natively inside your Atlassian Cloud environment. Your Jira data is never transmitted to, processed by, or stored on Velozar Labs servers.