Guide · Jira
NIS2 and change control in Jira: what to record
Approval Flow for Jira 3.0.0 is the production version (30 October 2026). Last updated 1 November 2026. On the Atlassian Marketplace.
By Bartosz Stankiewicz, founder, Stanki Guild.
NIS2 does not tell you to keep a change log in Jira. It tells certain organisations to manage the risks to their network and information systems, and change control is one of the places where those risks are managed or not. This guide reads the legal text, finds where change control sits in it, and lists what to record in Jira for each change so that you can show the procedure was followed. It is not legal advice. Whether NIS2 applies to you, and what your country's law requires, is a question for a lawyer.
The short answer: Article 21 of the directive asks for appropriate and proportionate risk measures and lists ten areas, and the word "change" does not appear in the list. Change control falls under the measures on policies, system maintenance and assessing whether the measures work. Explicit change management rules exist in a separate EU regulation, but only for certain kinds of entity. Either way, the records that serve you are the same: a documented, assessed, approved and tested change, and an explained emergency path.
What Article 21 says
#The directive is Directive (EU) 2022/2555, on EUR-Lex at eur-lex.europa.eu/eli/dir/2022/2555/oj. We read the Official Journal text on 1 November 2026. Article 21(1) says that essential and important entities must "take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems". Article 21(2) says the measures "shall include at least the following:" and lists ten points, (a) to (j). Three of them touch change control:
- (a) "policies on risk analysis and information system security;"
- (e) "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;"
- (f) "policies and procedures to assess the effectiveness of cybersecurity risk-management measures;"
None of them says "change management". Our reading is that a change procedure is how you show (e) in practice, and that its records are part of how you show (f). That is a reading, not a ruling, and your national law, which transposes the directive, may add detail.
Article 20 adds who is accountable. It says "Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21". That concerns the measures, meaning the change policy, not each individual change. A manager approving the policy is one record; the change approvals in Jira are another.
Article 21(4) is worth knowing for the emergency case: "an entity that finds that it does not comply with the measures provided for in paragraph 2 takes, without undue delay, all necessary, appropriate and proportionate corrective measures."
Where change management is explicit
#The Commission Implementing Regulation (EU) 2024/2690 sets technical and methodological requirements for the measures in Article 21(2) for a list of entity types. The regulation is on EUR-Lex at eur-lex.europa.eu/eli/reg_impl/2024/2690/oj, and we read its text on 1 November 2026. It applies to what it calls the relevant entities, which it names as DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking services platforms and trust service providers. If you are not one of those, the regulation does not bind you directly, but it is a published statement of what the Commission considers a sensible change procedure, and an auditor or a customer may point to it.
Its Annex, point 6.4 (Change management, repairs and maintenance), says:
- "The relevant entities shall apply change management procedures to control changes of network and information systems."
- The procedures apply to releases, modifications and emergency changes, and "shall ensure that those changes are documented and, based on the risk assessment carried out pursuant to point 2.1, tested and assessed in view of the potential impact before being implemented."
- For an emergency, the entity must "document the result of the change, and the explanation for why the procedures could not be followed".
- The procedures are reviewed and, where appropriate, updated at planned intervals and when significant incidents or significant changes to operations or risks occur.
What to record in Jira, per change
#This list follows the elements above. It is our suggestion for a record that shows the procedure was followed; it is not a checklist the law gives.
| What to record | Why (text it follows) | Native Jira |
|---|---|---|
| The change described: what, why, which systems | "documented" (6.4.2) | Work item with required fields |
| The risk and impact assessment, or a link to it | "based on the risk assessment" and "assessed in view of the potential impact" (6.4.2) | A required field or a linked page. Jira Service Management Premium has automated risk assessments |
| Test evidence before implementation | "tested ... before being implemented" (6.4.2) | Attachment or link in a required field |
| Approval, by whom and when | Authorisation (our addition: the text above does not use the word) | JSM approval step; Jira work item approvals need Premium |
| Implementation date and who did it | Control of the change | Work item history |
| Outcome: worked, rolled back, follow-up | "document the result of the change" (6.4.3, for emergencies; sensible for all) | A field and a comment |
| For an emergency: why the normal procedure was skipped | "the explanation for why the procedures could not be followed" (6.4.3) | A separate request type with a required field |
| Review of the change procedure on a date | "at planned intervals" (6.4.4) | A recurring task or a Confluence page with a review date |
A concrete tip for the emergency row: make "emergency" a request type of its own, with a required field for the reason. Then the explanation exists whether or not anyone remembers to write it.
Native first
#Jira and Jira Service Management give you a work item per change, required fields, workflow conditions on who can approve and a CSV export for sampling. On the Standard plan of Jira Service Management, Atlassian moved the change work category, change queues, change calendar and automated risk assessments to Premium and Enterprise (sourced on the toolkit page). Native approvals for Jira work items are a Premium feature: "The approvals feature is only available on Premium editions in Jira." If Premium fits your budget, use it.
Where our apps fit
#We make Checklist Flow, Approval Flow and Attestation Flow, so this is a vendor's view. Each is free, with every feature, for sites with up to 10 users, and priced per user above that.
- Checklist Flow turns "tested" and "rollback plan written" into required items that block the transition, and keeps a hash-chained history.
- Approval Flow records named approvers, a quorum, stages, a reason for every rejection and separation of duties, and blocks the transition until every required sign-off is in.
- Attestation Flow records that named people read the new version of a Confluence runbook.
Each exports its own records as files. There is no combined evidence pack, and nothing connects a change to a runbook acknowledgement automatically. The step-by-step version, with what none of the apps do, is the change control toolkit.
What we have not shown live yet
#We have not run this setup on a Jira Service Management Standard site with a change request type. We hold no NIS2 or ISO 27001 certification, and our apps do not make an organisation compliant with NIS2 or any other law or standard. They produce records. This guide is not legal advice; ask a lawyer whether NIS2 applies to you and what your national law requires.
Common questions
#Does NIS2 require change management?
Article 21 of the directive does not use the term. It requires appropriate and proportionate risk measures, and a change procedure is a natural part of them. For the entity types named in Implementing Regulation (EU) 2024/2690, point 6.4 of its Annex requires change management procedures explicitly.
Does the implementing regulation apply to us?
Only if you are one of the entity types it names, such as a cloud computing service provider, a managed service provider or a data centre service provider. Your country's law and your own situation decide the rest, so ask a lawyer.
What should an emergency change record contain?
The regulation text says to document the result of the change and the explanation for why the procedures could not be followed. A request type of its own with a required reason field makes that explanation exist for every emergency change.
Do your apps make us NIS2 compliant?
No. They produce records of checks, approvals and acknowledgements. Whether those records satisfy the law is for you, your auditor and your lawyer to decide.
Related
#- Approval Flow for Jira documentation
- Jira approval templates
- Approval Flow compared with other Jira apps
- Jira sign off: how to require a sign-off before a work item moves on
- Multiple approvers in Jira without Jira Service Management: 3 ways compared
- Which Jira and Confluence plans include approvals
- Jira approval workflow example: a purchase approval with three spend tiers
- Jira approval step skips the workflow validator: what you can do
- Jira: require a comment when someone approves or declines
- Jira approval: 50% plus one when the approver group keeps changing
- Jira approvals when the approver is out of office
- Jira approval reminders that repeat until the approver acts
- Release approval in Jira: what exists before a version is released
- Jira release approval process: how to record who approved a release and when
- Is a Slack approval valid audit evidence? What to record in Jira instead
- ISO 27001 change management evidence in Jira: what to keep for Annex A 8.32
- Jira approvals in Slack, Microsoft Teams and e-mail, without losing who decided
- Approval Flow with ScriptRunner for Jira Cloud: read approval status in scripts
- How we test approval rules in Jira: a million random cases a night
- Our nightly tests went red on the first run. The app was right.