ISO/IEC/IEEE 23612:2026

International
Standard
ISO/IEC/IEEE 23612
First edition
Software and systems
2026-05
engineering — Incident
management
Ingénierie du logiciel et des systèmes — Gestion d'incident
Reference number © ISO/IEC 2026
© ISO/IEC 2026
© IEEE 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
ii
Contents Page
Foreword .iv
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Conformance . 2
4.1 Intended usage .2
4.2 Full conformance .2
4.3 Tailored conformance .2
5 Incident management process . 3
5.1 Overview .3
5.2 Purpose .5
5.3 Outcomes .5
5.4 Activities and tasks .5
5.4.1 General .5
5.4.2 Plan and implement incident management (IM1) .5
5.4.3 Raise incident (IM2) .6
5.4.4 Confirm incident (IM3) .6
5.4.5 Analyse and decide response (IM4) .6
5.4.6 Resolve incident (IM5) .7
5.4.7 Confirm resolution (IM6) .7
5.4.8 Close incident (IM7) .8
5.4.9 Monitor and report on incidents (IM8) .8
5.4.10 Incident analysis and improvement (IM9) .8
5.5 Information items .8
Annex A (informative) Incident states . 10
Annex B (informative) Incident management data collection .15
Annex C (normative) Incident documentation templates . 17
Annex D (informative) Incident documentation examples .26
Annex E (informative) Incident severity and priority .28
Annex F (informative) Incident management measures .31
Annex G (informative) Creating incident report titles .32
Bibliography .34
IEEE notices and abstract .35

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of
IEEE or IEEE SA and participate without compensation from IEEE. While IEEE administers the process and
establishes rules to promote fairness in the consensus development process, IEEE does not independently
evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained
in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
iv
International Standard ISO/IEC/IEEE 23612:2026(en)
Software and systems engineering — Incident management
1 Scope
This document defines a generic incident management process and supporting documentation that can be
used to implement incident management and to manage incidents within most organizations, projects or
operations activities for a system, service, software, or product. This document also provides supporting
diagrams describing the process and example documents.
This document is applicable to incident management in all life cycle models (e.g. incremental, waterfall,
evolutionary, agile). This document covers incidents identified across the life cycle, including those that arise
during both development (e.g. defects) and operation (e.g. those handled by service management).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC and IEEE maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
— IEEE Standards Dictionary Online: available at: http:// dictionary .ieee .org
NOTE Definitions for other systems and software engineering terms typically can be found in ISO/IEC/IEEE 24765,
available at www .computer .org/ sevocab.
3.1
defect
imperfection or deficiency in a work product where that work product does not meet its requirements or
specifications
Note 1 to entry: Requirements are not always documented and can contain defects.
[SOURCE: ISO/IEC/IEEE 32675:2022, 3.1, modified — The words ‘or characteristic’ have been removed; the
words "where" and "work product" have been added; note 1 to entry has been added.]
3.2
incident
anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of a
project, product, service, or system
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.17, modified — Note 1 to entry has been deleted.]
3.3
incident management
process of recognizing, logging, investigating, classifying, and acting on incidents (3.2), and recovery to the
normal state
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.4
incident report
documentation of the occurrence, nature and status of an incident (3.2)
Note 1 to entry: Incident reports are also known as anomaly reports, bug reports, defect (3.1) reports, error reports,
and trouble reports, amongst other terms.
[SOURCE: ISO/IEC/IEEE 29119-3:2021, 3.4, modified — In note 1 to entry, "issues" and "problem reports"
have been removed.]
3.5
incident management report
documentation summarizing the occurrence, nature and status of recorded incidents (3.2) over a specified
period
3.6
priority
degree of urgency to resolve an incident (3.2) or an underlying problem (3.7), based on its impact to the
stakeholders as well as the cost and risk of the fix
Note 1 to entry: The priority is time-variant, as it is dependent on the current phase of the project life cycle
3.7
problem
cause of one or more actual or potential incidents (3.2)
[SOURCE: ISO/IEC 20000-10:2018, 3.2.10]
3.8
severity
degree of impact that an incident (3.2) or underlying problem (3.7) has on the development, testing or
operation of a system, software or product
4 Conformance
4.1 Intended usage
The incident management process shall be in accordance with Clause 5. The test documentation shall be in
accordance with Annex C.
It is recognized that particular projects or organizations may not need to use the complete process defined
by this document. Therefore, implementation of this document typically involves selecting a set of activities
suitable for the software and systems development, testing or operations. There are two ways that an
organization can claim to conform to the provisions of this document.
The organization shall assert whether it is claiming full or tailored conformance to this document.
4.2 Full conformance
Full conformance is achieved by demonstrating that all of the requirements of the process defined in Clause 5
and the test documentation defined in Annex C have been met.
4.3 Tailored conformance
When this document is used as a basis for establishing an incident management process that does not qualify
for full conformance, the subset of activities for which tailored conformance is claimed shall be recorded.
Tailored conformance is achieved by demonstrating that all of the requirements for the recorded subset of
activities have been satisfied.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
When this document is used as a basis for establishing a set of incident management documentation that
does not qualify for full conformance, the subset of documentation for which tailored conformance is
claimed shall be recorded. Tailored conformance is achieved by demonstrating that all requirements for the
recorded subset of incident management documentation defined in Annex C have been satisfied.
Where tailoring occurs, justification shall be provided (either directly or by reference), whenever an activity
defined in Clause 5 is not followed or the requirements for incident management documentation in Annex C
are not met. All tailoring decisions shall be recorded with their rationale, including the consideration of any
applicable risks. Tailoring decisions shall be agreed by the relevant stakeholders.
EXAMPLE Where organizations follow information item management processes in standards such as ISO 15489-1,
ISO 9001, ISO/IEC 20000-1 or use similar internal organizational processes, they can decide to use those processes in
place of the information item management tasks defined in this document.
5 Incident management process
5.1 Overview
The incident management process shown in Figure 1 is used to both manage the set of incidents identified
across a project, a service or organization (see IM1, IM8 and IM9 in Figure 1), and individual incidents from
their occurrence to their closure (see IM2 to IM7 in Figure 1).
Incident management includes planning how incidents are to be handled by a project or organization (the
first activity, IM1, in Figure 1), monitoring and reporting on the status of these incidents (IM8 in Figure 1),
and how these incidents are analysed to improve subsequent performance in the project or organization (the
final activity, IM9, in Figure 1). The core of this process (IM2 to IM7 in Figure 1) is formed by the activities
for managing individual incidents, in which some activities can be combined, for instance, if the project is
small. As each individual incident progresses through this process, it passes through several states, such as
raised, confirmed, under resolution and closed. Possible states and the possible transitions between them
are shown in the state models provided in Annex A.
Incidents can be raised at any point in the life cycle of the system, software or product, and can be as a
result of operational use, review, development or testing activities. Incident management can result in the
correction of defects or the improvement of the product, as well as improvements to the processes by which
the system is used, developed, reviewed, or tested.
The incident management process is often specified as part of a generic incident management plan, which
can be defined as an organizational practice that can be applied to all projects in an organization. In some
situations, this requires the generic plan to be customized for individual projects. Ideally any customization
still allows the comparison of incident management measures from different projects and the sharing of
potential improvements to the implemented processes. Typical inputs to this process include:
— previous or current incident management processes; and
— current development, verification, validation, test and operational practices.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
NOTE 1 Some of the activities in this figure are often combined in practice for smaller projects, organizations or
systems.
NOTE 2 Not all possible transitions are shown. Some transitions, notably those that move backwards (e.g. from IM6
to IM5 or IM4), are not shown to increase clarity.
Figure 1 — Incident management process

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
5.2 Purpose
The purpose of the incident management process is to optimally manage all incidents to resolution.
When managing incidents at a high level (e.g. organization or project level), the incident management
process is planned and agreed, and the information gathered from reported incidents is used to improve the
relevant processes.
When an individual incident requires a response, the work is assigned to a suitable party for resolution, and
the resolution activities are monitored for acceptability. Once the resolution is approved, then the incident is
closed, and the incident management process for that individual incident is deemed complete.
5.3 Outcomes
As a result of the successful implementation of the incident management process:
a) the incident management plan is agreed;
b) incidents are raised and confirmed;
c) confirmed incidents are analysed and assigned for response;
d) incidents are resolved;
e) incident resolution is monitored;
f) the resolution of incidents is verified, and the incidents are closed;
g) incident report data is collected to be used for future analysis;
h) incidents are analysed, and improvements actioned.
5.4 Activities and tasks
5.4.1 General
The personnel responsible for incident management implement the following activities and tasks in
accordance with applicable organization policies and procedures with respect to the incident management
process.
5.4.2 Plan and implement incident management (IM1)
This activity consists of the following tasks:
a) The incident management plan shall be established.
b) The incident management plan shall be agreed by the relevant stakeholders.
c) The incident management plan shall be communicated to the relevant stakeholders.
EXAMPLE Stakeholders can include head of quality assurance, head of development, head of testing and head
of service management.
NOTE This group of stakeholders can include anyone who takes part in the incident management process,
such as those who are expected to confirm and analyse incidents, those who decide responses, and those who
resolve incidents and check their resolution.
d) The process for analysing incidents to identify potential improvements:
1) should be defined;
2) should be recorded;
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3) should be agreed by the relevant stakeholders;
4) should be communicated to the relevant stakeholders as part of the incident management plan.
e) The incident management plan shall be implemented.
5.4.3 Raise incident (IM2)
This activity consists of the following tasks:
a) Details of the incident shall be recorded as part of an incident report, including a status indicating that it
has been raised.
NOTE 1 Incidents can be raised by a wide variety of stakeholders, such as users, testers and developers, or
automatically by an autonomous system (see D.3.3).
NOTE 2 At this point in the incident management process, only a subset of the fields in the incident report
can be completed. Annex B shows the typical incident information collected at various points in the incident
management process.
b) The incident report shall be communicated to the relevant stakeholders as detailed in the incident
management plan.
EXAMPLE Incident reports can be collected and communicated to the relevant stakeholders using an incident
management tool, a test management tool, or on paper.
5.4.4 Confirm incident (IM3)
This activity consists of the following tasks:
a) The incident shall be evaluated to confirm whether it requires further action.
NOTE 1 In larger organizations, this activity is sometimes handled by a team responsible for handling
incidents, such as a defect triage team or service desk.
b) If further action is required:
1) the incident report shall be updated to reflect the result of the evaluation;
2) the incident status shall be communicated to relevant stakeholders;
3) the incident shall be assigned to a person or team with the relevant expertise, time and skills to
perform an effective analysis of the incident;
4) the incident shall be progressed to the analyse and decide response activity (5.4.5).
NOTE 2 If the reported incident appears to be a duplicate of a previously raised incident, the two incident
reports are usually linked together, and one is closed.
NOTE 3 If the reported incident appears to be related to a previously raised incident, the two incident reports
are usually linked together.
c) If no further action is required:
1) the incident report shall be updated with the justification for its closure;
2) the incident shall be progressed to the close incident activity (5.4.8).
5.4.5 Analyse and decide response (IM4)
This activity consists of the following tasks:
a) The incident shall be analysed to gather sufficient information to determine if it requires resolution or
not.
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
b) If the incident requires resolution:
1) the incident shall be assigned to a person or team for resolution;
2) the incident shall be progressed to the resolve incident activity (5.4.6);
3) a person or team should be assigned to monitor its resolution as part of the confirm resolution
activity (5.4.7);
4) the incident report shall be updated with resolution information.
EXAMPLE Resolution information typically includes expectations such as the target version for the
resolution, reporting requirements, and acceptance criteria.
NOTE In some situations, resolution is not practical, and mitigating actions are more appropriate.
c) If the incident does not require resolution:
1) the incident report shall be updated with the justification for its closure;
2) the incident shall be progressed to the close incident activity (5.4.8).
5.4.6 Resolve incident (IM5)
This activity consists of the following tasks:
a) Corrective actions to resolve or mitigate the incident shall be performed.
NOTE 1 Sometimes the person or team assigned to perform incident resolution find that they cannot resolve
the incident due to various factors, such as time or effort constraints, lack of available skills or tools, the inability
to reproduce the incident, or a misunderstanding about the functionality, in which case the incident is returned to
the analyse and decide response activity (5.4.5).
b) The changes made should be tested to provide confidence that the corrective actions successfully
addressed the incident and caused no unintended regressions elsewhere in the system.
NOTE 2 If the corrective actions failed to successfully address the incident, the incident report is updated
to include any additional useful information gathered about the incident and further corrective actions are
performed by returning to task a).
NOTE 3 In some circumstances testing is not necessary, such as when the change is fixing a typographical
error.
c) The incident report shall be updated to reflect the corrective actions taken and testing performed.
NOTE 4 Some corrective actions have an effect on other artefacts, such as other subsystems or documentation.
d) The result of the incident resolution and the status of the incident shall be communicated to relevant
stakeholders.
NOTE 5 During development, corrective actions are normally the responsibility of the development team, while,
once operational, the corrective actions often become the responsibility of a maintenance team.
5.4.7 Confirm resolution (IM6)
This activity consists of the following tasks:
a) Once the corrective actions are reported as completed, the results shall be checked to confirm that the
incident has been successfully resolved.
EXAMPLE Checking test results, or re-running confirmation and regression tests.
b) The incident report shall be updated to reflect the resolution result and the target build or version.
c) Resolved incidents shall be progressed to the close incident activity (5.4.8).

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
d) Unresolved incidents shall either be returned to the resolve incident activity (5.4.6) for additional
resolution actions or to the analyse and decide response activity (5.4.5) for further analysis to decide an
alternative response.
5.4.8 Close incident (IM7)
This activity consists of the following tasks:
a) The incident report shall be updated to reflect approval that the incident has been addressed and the
incident status is changed to closed.
b) A closure reason shall be recorded for each incident, to support future incident analysis and improvement
activities.
c) The incident report should be stored for subsequent analysis in the incident analysis and improvement
activity (5.4.10).
5.4.9 Monitor and report on incidents (IM8)
This activity consists of the following tasks:
a) The timeliness of corrective actions and the success of these actions against the acceptance criteria
should be monitored by a person or team independent of those implementing the actions.
b) The collective status of reported incidents shall be determined using relevant metrics (see Annex F).
c) The collective status of reported incidents shall be communicated to relevant stakeholders in the
incident management report for the specified reporting period.
5.4.10 Incident analysis and improvement (IM9)
This activity consists of the following tasks:
a) Closed incidents should be analysed to identify root causes and possible improvements.
NOTE 1 In some circumstances, the analysis also includes incidents which have not yet been closed.
NOTE 2 Analysis can identify areas of the system and development process that are problematic, which can be
improved in the current or future projects. These areas include:
— the causes of incidents (i.e. problems), which can include technical, managerial, and human factors;
— product weaknesses;
— poor test practices;
— poor incident management practices.
b) Identified improvements should be recorded.
c) Identified improvements should be communicated to the relevant stakeholders for action.
5.5 Information items
As a result of carrying out this process, the following information items shall be produced:
a) incident management plan;
b) incident reports;
c) incident management reports.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
NOTE Document templates for the incident management plan, incident reports and incident management report
are provided in Annex C. An example incident management plan, example incident reports and an example incident
management report are provided in Annex D.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Annex A
(informative)
Incident states
A.1 Overview
The individual incident reports can be considered in terms of progressing through a number of states that
can be represented as a state model. This annex provides a high-level view of those states (see Figure A.1)
and an example implementation as a state machine in Figure A.2.
A.2 Simplified state model
Figure A.1 represents the progression of individual incident report states through the incident management
process. This is a very simplified state model. In practice it is often more detailed, and with more states, as
is shown in Figure A.2.
Figure A.1 — Incident states
A.3 Incident report state machine example
Figure 1 shows the incident management process as a series of activities. Incident management tools typically
implement many of these activities in the form of a state machine. In such tools, an incident report moves
from one state to the other as a result of actions completed by the development and testing organizations.
Each activity in the incident management process can be represented by one or more states, which allows
control of the resolution of incidents.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
The actual state machine implemented varies among organizations based on their development processes,
organization chart and role definitions. This annex provides one example of such a state machine, applied
to defect management, with states associated with the activities of the incident management process
defined in Clause 5, as shown in Figure A.2. Organizations can opt to have more, fewer or different states
that implement the incident management process. For instance, an additional deferred state is sometimes
included.
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
NOTE 1 The references (IM2 to IM7) are to the activities related to individual incidents in the incident management
process defined in Clause 5.
NOTE 2 Solid lines represent the transitions that model the primary use case. Dashed lines represent alternative
transitions that occur less frequently.
Figure A.2 — Incident report state machine example

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Table A.1 provides descriptions of the states shown in Figure A.2 and maps the states to the activities in the
incident management process defined in Clause 5.
Table A.1 — Descriptions of example incident report states
State Description Process step
The starting state of every new incident report.
New incident IM2
The incident is recorded in the initial version of an incident report.
The incident is identified as a defect.
New defect IM3
In this state the severity and priority of the defect are agreed upon.
The defect is assigned to an owner, usually a developer, to fix it.
Assigned IM4
In some cases, the fix can be to requirements or documentation.
Additional information is required to address the incident.
The ownership of the defect is transferred to a person who can provide the
Waiting for
missing information. Usually, it is the person reporting the incident, but it can IM4
inputs
be others, e.g. architect or person responsible for marketing.
No work is done on the defect until the information is provided.
Work in progress The owner has started to work on resolving the defect. IM5
If the fix is in the code, the code has been checked into the main branch. The
status is not yet marked as “fixed” since the fixed code is not yet in a released
build. A similar case is when a defect in the documentation is fixed, and the
documentation is released as part of a build.
Committed IM5
If the fix is to requirements or other systems where a fix is immediately in
effect (no need to wait for another step, such as a release of a build), the “Com-
mitted” status is a transient one; right after setting the status of the incident to
“Committed” it will be moved forward to “Fixed”.
For a fix in code: the fix is now released in an official build.
Fixed IM5
For textual fix: The update is in the relevant systems and can be reviewed.
Confirming Checking that the fix has been made correctly. IM6
A confirmation test was performed, and the fix was found to be lacking (does
Not fixed IM6
not fully fix the reported incident).
The incident was rejected as invalid for various reasons. Common reasons are:
— Duplicate (the incident is already reported).
— By design (or: “not a defect”): The reporter made an error when
reporting the incident: the test item works as designed.
— Cannot reproduce: The incident cannot be reproduced following the
Rejected N/A
description in the incident report, hence cannot be fixed.
— Will not fix: The incident is indeed a defect, but project management
decided not to fix it.
Different organizations can have more, fewer or different reasons.
Note that incidents can be rejected at various process steps (IM2-IM5).
The incident is closed, and no more work needs to be invested in it.
Closed IM7
Incidents are usually closed when the fix has been verified, or when the report-
er agrees that the incident should be rejected.
Incident reports are moved from one state to another via transitions (see examples in Table A.2). The example
state machine in Figure A.2 shows one option for a set of transitions for an incident report. Organizations
can opt to have more, fewer or different transitions.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Table A.2 — Descriptions of example incident report transitions
Transition Description
T1 The incident was reviewed and agreed to be a defect.
T2 The defect was assigned to an owner.
T3 The owner started to resolve the incident.
T4 The fix was completed. The changes were updated in the relevant system (code; requirements man-
agement; documentation etc.).
T5 The fix exists in an official build and can be confirmed.
T6 Confirmation test of the fix was initiated.
The fix was confirmed to be successful.
T7
NOTE If the fix test identified a new, different incident, the current incident report will be closed,
and a new one opened.
T8 The fix was not successful.
T9 The defect was assigned to an owner
T10 See Table A.1 for reasons why an incident can be rejected.
It is important to document the reason why an incident was moved to Rejected state, for future
improvement activities (process step IM8). Additionally, it lets the incident reporter understand the
rejection reason and to dispute it when needed.
An incident in state “rejected” can be returned to states "Assigned", "Work in progress" or "New
defect", if it were found that the rejection was in error.
When an incident at state “New (incident)” is rejected in error, it means the incident is a defect, and
so the transition is from the "Rejected" state to the "New (defect)" state.
T11 The incident owner needs further information to be able to resolve the incident.
Once the information is provided, the incident is returned to the state from which the request for
information was generated.
T12 The reason for rejection is accepted and the incident can be closed.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Annex B
(informative)
Incident management data collection
Most incident management systems allow the user to tailor the collection of information based on the
needs of the project and organization. Below is a typical set of information at various stages of the incident
management process that could be useful to collect regardless of the type of system. Refer to Annex C for
details on each information item listed here.
When raising an incident, the following information is typically recorded:
— unique identifier;
— title;
— summary;
— references;
— originator;
— reporting date;
— status (this is updated at each subsequent stage);
— context:
— artefact;
— environment;
— activity;
— detailed description;
— supporting information;
— severity;
— updated change log (this is updated at each subsequent stage).
After the incident has been evaluated and confirmed as requiring further action, the following additional
information is typically recorded:
— incident type;
— priority;
— person or team assigned to analyse the incident report.
After the incident has been evaluated, and it is decided that no further action is required, the following
additional information is typically recorded:
— justification for no further action.
After the incident has been analysed, and it is decided that it needs to be resolved, the following additional
information is typically recorded:
— person or team assigned to resolve the incident;

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
— person or team assigned to monitor the resolution of the incident;
— date assigned;
— target version for the incident to be fixed;
— reporting requirements;
— acceptance criteria.
After the incident has been analysed, and it is decided that it does not require resolution, the following
additional information is typically recorded:
— justification for the decision not to resolve the incident.
After the incident has been resolved, the following additional information is typically recorded:
— details of corrective actions (including any secondary effects on other subsystems or systems, if any);
— testing details (updated in the monitor resolution activity).
As part of the monitor resolution activity, the following additional information is typically recorded:
— the success, or not, of the resolution;
— date the incident was confirmed as resolved and tested;
— version or build of artefact in which the incident is resolved.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Annex C
(normative)
Incident documentation templates
C.1 Introduction
This annex describes the information to be included in an incident management plan (C.2), an incident report
(C.3), and an incident management report (C.4).
This annex also explains how the requirements, recommendations and permissions of the activities and
tasks of the incident management process map to the test documentation templates defined in this annex.
In practice these documents do not have to be published as a single hardcopy document, but may be made
available on paper or in electronic form (e.g. records in incident management tools, spreadsheets, mind
maps, white board photos) and may be divided into separate documents, or combined with other documents.
The incident documentation titles, headings and layout described in this annex may be modified (e.g. added
to, combined or re-titled).
Examples of an incident management plan, incident reports and an incident management report are provided
in Annex D.
C.2 Incident management plan
C.2.1 Overview
The incident management plan addresses the process that defines how individual incidents will be raised,
confirmed, analysed, resolved, monitored and closed. It also addresses how incidents will be analysed and
improvements determined.
The contents of the incident management plan include the content defined under C.2.2 to C.2.19.
C.2.2 Unique identifier
Uniquely identifies the incident management plan.
C.2.3 Issuing organization
Specifies the organization responsible for preparing and releasing the incident management plan. It can also
include authors.
C.2.4 Approval authority
Identifies the designated persons who have the responsibility for signing off on the incident management
plan.
C.2.5 Change history
Includes a log of all of changes made to the incident management plan since its inception.
C.2.6 Status
Defines the status of the incident management plan.
EXAMPLE Incident management plan status can include "in preparation", "under review" and "approved."

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
C.2.7 Introduction
Explains the context and structure of the incident management plan.
C.2.8 Scope
Identifies the extent of the coverage of incident management by the incident management plan, and describes
any inclusions, exclusions, assumptions and/or limitations.
EXAMPLE The plan is restricted in scope to only managing defects reported during testing.
C.2.9 References
Lists other referenced documents or records.
EXAMPLE Project plans, test plans, life cycle processes, standards, regulatory requirements.
C.2.10 Glossary
Provides a lexicon for the terms, abbreviations, and acronyms, if any, used in the incident management plan.
NOTE This section can be an annex, or it can refer to another item of project or organizational documentation
that provides a general glossary.
C.2.11 Assumptions and constraints
Describes any assumptions and constraints for incident management covered by this plan. These can be
related to regulatory standards, the requirements in the quality assurance policy, contractual requirements,
...