ISO/IEC/IEEE 15026-1
(Main)Systems and software engineering — Systems and software assurance — Part 1: Vocabulary and concepts
Systems and software engineering — Systems and software assurance — Part 1: Vocabulary and concepts
This document defines assurance-related terms and establishes an organized set of concepts to form a basis for shared understanding in the field of assurance. It benefits users of ISO/IEC/IEEE 15026-2, ISO/IEC/IEEE 15026-3 and ISO/IEC/IEEE 15026-4. Vocabulary and concepts for assurance of a service being operated and managed on an ongoing basis is not covered in this document. While essential to assurance practice, details regarding exactly how to measure, demonstrate or analyse particular properties are not covered.
Ingénierie des systèmes et du logiciel — Assurance des systèmes et du logiciel — Partie 1: Vocabulaire et concepts
General Information
Relations
Standards Content (Sample)
FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
15026-1
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — Systems and
Voting begins on:
software assurance —
2025-07-21
Part 1:
Voting terminates on:
2025-09-15
Vocabulary and concepts
Ingénierie des systèmes et du logiciel — Assurance des systèmes
et du logiciel —
Partie 1: Vocabulaire et concepts
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number © ISO/IEC 2025
ISO/IEC/IEEE FDIS 150261:2025(en) © IEEE 2025
FINAL DRAFT
ISO/IEC/IEEE FDIS 15026-1:2025(en)
International
Standard
ISO/IEC/IEEE
FDIS
15026-1
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — Systems and
Voting begins on:
software assurance —
Part 1:
Voting terminates on:
Vocabulary and concepts
Ingénierie des systèmes et du logiciel — Assurance des systèmes
et du logiciel —
Partie 1: Vocabulaire et concepts
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
© ISO/IEC 2025
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© IEEE 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
respective address below or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
ISO copyright office Institute of Electrical and Electronics Engineers, Inc MADE IN NATIONAL REGULATIONS.
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
Reference number © ISO/IEC 2025
ISO/IEC/IEEE FDIS 150261:2025(en) © IEEE 2025
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ii
ISO/IEC/IEEE FDIS 15026-1:2025(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Terms related to assurance .1
3.2 Terms related to system life cycles .4
3.3 Terms related to integrity level .6
3.4 Terms related to risks and dependability .7
4 Basic concepts .10
4.1 General .10
4.2 Assurance .10
4.3 Stakeholders .11
4.4 System and product.11
4.5 Property .11
4.5.1 General .11
4.5.2 Properties as behaviours . 12
4.6 Uncertainty and confidence . 12
4.7 Conditions and initiating events . 12
4.8 Consequences . 13
5 Using multiple parts of the ISO/IEC/IEEE 15026 series .13
5.1 General . 13
5.2 Initial usage guidance . 13
5.3 Relationships among parts of the ISO/IEC/IEEE 15026 series .14
5.4 Authorities.14
6 The ISO/IEC/IEEE 15026 series and the assurance case . 14
6.1 General .14
6.2 Justification of method of reasoning . 15
6.3 Means of obtaining and managing evidence .16
6.4 Certifications and accreditations .16
7 The ISO/IEC/IEEE 15026 series and integrity levels .16
7.1 General .16
7.2 Risk analysis .17
8 The ISO/IEC/IEEE 15026 series and the life cycle . 17
8.1 General .17
8.2 Assurance activities in the life cycle .18
Bibliography . 19
IEEE notices and abstract .25
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
iii
ISO/IEC/IEEE FDIS 15026-1:2025(en)
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 the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards
through a consensus development process, approved by the American National Standards Institute, which
brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE
administers the process and establishes rules to promote fairness in the consensus development process,
the IEEE does not independently evaluate, test, or verify the accuracy of any of the information 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.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 15026-1:2019), which has been
technically revised.
The main changes are as follows:
— definitions of terms introduced in other parts of the ISO/IEC/IEEE 15026 series have been added or
modified;
— definitions of terms whose definitions were sourced from ISO/IEC 15288 and ISO/IEC/IEEE 24774 have
been updated.
A list of all parts in the ISO/IEC/IEEE 15026 series can be found on the ISO and IEC websites.
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 2025, © IEEE 2025 – All rights reserved
iv
ISO/IEC/IEEE FDIS 15026-1:2025(en)
Introduction
Software and systems assurance and closely related fields share concepts but have different vocabularies
and perspectives. This document provides an unambiguous use of vocabulary for systems and software
assurance and a unifying set of underlying concepts across these various fields. It provides a basis for
elaboration, discussion and recording agreement and rationale regarding concepts and the vocabulary used
uniformly across the ISO/IEC/IEEE 15026 series.
Clause 4 covers basic concepts such as assurance, stakeholders, systems and products, property, uncertainty
and confidence, conditions and initial events, and consequence. Clause 5 covers some issues of which
users of ISO/IEC/IEEE 15026-2, ISO/IEC/IEEE 15026-3 and ISO/IEC/IEEE 15026-4 should be initially
aware (5.2). Clause 6, Clause 7 and Clause 8 cover concepts relevant to users of ISO/IEC/IEEE 15026-2,
ISO/IEC/IEEE 15026-3 and ISO/IEC/IEEE 15026-4, respectively; also, users of one of these parts can benefit
from the clauses for other parts.
The essential concepts introduced by the ISO/IEC/IEEE 15026 series are the claims in an assurance case and
the support of claims in terms of argument and evidence. These claims are in the context of assurance for
properties of systems and software within life cycle processes for the system or software product.
Potential users of the ISO/IEC/IEEE 15026 series are developers and maintainers of assurance cases
and those who wish to develop, sustain, evaluate or acquire a system that possesses requirements for
specific properties in such a way as to be more certain of those properties and their requirements. The
ISO/IEC/IEEE 15026 series uses concepts and vocabulary consistent with ISO/IEC/IEEE 12207 and
ISO/IEC/IEEE 15288 and generally consistent with the standards on Systems and software Quality
Requirements and Evaluation (SQuaRE) developed by JTC 1/SC 7, but the concepts and vocabulary provided
by the ISO/IEC/IEEE 15026 series can differ from those to which the potential user is accustomed. This
document attempts to clarify these differences.
The ISO/IEC/IEEE 15026 series is made up of the following parts.
— ISO/IEC/IEEE 15026-1 explains concepts and terms as a basis for all parts of the ISO/IEC/IEEE 15026 series.
— ISO/IEC/IEEE 15026-2 includes requirements on the structure of the assurance case.
— ISO/IEC/IEEE 15026-3 relates integrity levels to the assurance case and includes requirements for their
use with and without an assurance case.
— ISO/IEC/IEEE 15026-4 provides guidance and recommendations for assurance of a selected claim
about the system-of-interest by achieving the claim and showing the achievement. The guidance and
recommendations are given in a system assurance process view on top of ISO/IEC/IEEE 15288 and a
software assurance process view on top of ISO/IEC/IEEE 12207.
The assurance case is relevant to a greater or lesser extent in all parts of the ISO/IEC/IEEE 15026 series,
although ISO/IEC/IEEE 15026-4 discusses achieving the claim and showing the achievement of the claim
whether or not such “showing” is contained in an artefact specifically called an “assurance case”.
ISO/IEC/IEEE 15026-2 concentrates on the contents and structure of the assurance case.
ISO/IEC/IEEE 15026-3 relates integrity levels and assurance cases by describing how integrity levels and
assurance cases can work together, especially in the definition of specifications for integrity levels or by
using integrity levels within a portion of an assurance case. This relationship is governed by the degree of
risk and dependencies in the system.
ISO/IEC/IEEE 15026-4 includes assurance-related guidance and recommendations for activities across the
life cycle processes including activities that extend beyond those directly related to an assurance case, e.g.
project planning for assurance-related considerations.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
v
FINAL DRAFT International Standard ISO/IEC/IEEE FDIS 15026-1:2025(en)
Systems and software engineering — Systems and software
assurance —
Part 1:
Vocabulary and concepts
1 Scope
This document defines assurance-related terms and establishes an organized set of concepts to form
a basis for shared understanding in the field of assurance. It benefits users of ISO/IEC/IEEE 15026-2,
ISO/IEC/IEEE 15026-3 and ISO/IEC/IEEE 15026-4.
Vocabulary and concepts for assurance of a service being operated and managed on an ongoing basis is not
covered in this document.
While essential to assurance practice, details regarding exactly how to measure, demonstrate or analyse
particular properties are not covered.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
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 https:// ieeexplore .ieee .org/ xpls/ dictionary .jsp
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software
engineering vocabulary) database and is publicly accessible at https:// www .computer .org/ sevocab.
3.1 Terms related to assurance
3.1.1
assurance
grounds for justified confidence that a claim (3.1.10) has been or will be achieved
Note 1 to entry: By definition, assurance is about a claim.
Note 2 to entry: The claim can be a conjunction of more than one claim.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.1.2
assurance argument
artefact that links tangible evidence (3.1.15) and assumptions to provide a convincing and valid argument of
a claim (3.1.10) under a given context
Note 1 to entry: An assurance argument provides the reasoning that connects the evidence (and assumptions) to the
claim. It explains 'why' the evidence supports the claim and how the evidence is relevant.
Note 2 to entry: An argument is valid only if all of its premises being true implies that its conclusion is true.
3.1.3
assurance case
auditable artefact that provides a convincing and sound argument for a claim (3.1.10) on the basis of tangible
evidence (3.1.15) under a given context
Note 1 to entry: Premises of an argument are propositions, and all propositions are either true or false.
Note 2 to entry: An argument is sound only if it is valid and contains only true premises.
Note 3 to entry: An argument is not sound if it is valid but contains some false premises.
3.1.4
assurance case report
auditable artefact that provides the claim (3.1.10) of an assurance case (3.1.3) and a complete index of
the argument and evidence (3.1.15) of the assurance case such that the assurance case of interest can be
assembled from the index
Note 1 to entry: An assurance case report is mapped to the report field. An assurance case report is an introduction to
the assurance case. Its content varies from one case to another. For simple assurance cases, a report can be superfluous.
For larger or more complex assurance cases the report can include a system (3.2.8) description, some of the argument
and its supporting evidence e.g. the higher-level arguments and their supporting evidence.
Note 2 to entry: Assurance case reports are often issued as periodic updates to the assurance case at pre-agreed
points such as at the end of a life cycle stage. They report on results of assurance activities done so far, an assessment
of overall progress and a review of assurance activities’ performance. Assurance case reports can be used at decision
gates for stage exit/entry by suppliers and for project monitoring by acquirers.
3.1.5
assurance claim
claim (3.1.10) for which assurance (3.1.1) is considered
3.1.6
assurance information
information including a claim (3.1.10) about a system (3.2.8), evidence (3.1.15) supporting the claim, an
argument showing how the evidence supports the achievement of the claim, and the context for these items
Note 1 to entry: The sub-claims included in the argument of assurance information can be about the life cycle of the
system-of-interest (3.2.10) when, for example, the top-level claim implies continuous achievement of some property
(3.1.17).
Note 2 to entry: ISO/IEC/IEEE 15026-2 specifies assurance cases (3.1.3) that documents assurance information.
3.1.7
assurance objective
purpose of achievement of the assurance claim (3.1.5)
Note 1 to entry: Assurance objectives determine the required degree of integrity level (3.3.1) and permissible
uncertainty in the assurance information (3.1.6).
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.1.8
attribute
inherent property (3.1.17) or characteristic of an entity that can be distinguished quantitatively or
qualitatively by human or automated means
Note 1 to entry: ISO 9000 distinguishes two types of attributes: a permanent characteristic existing inherently in
something; and an assigned characteristic of a product (3.2.6), process (3.2.4), or system (3.2.8) (e.g. the price of a
product, the owner of a product).
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.2]
3.1.9
basic assumption
assumption in a collection of claims (3.1.10) shared by assurance cases (3.1.3) in a specific field
Note 1 to entry: Such a collection corresponds to a set of axioms in formal system in logic.
3.1.10
claim
true-false statement about the limitations on the values of an unambiguously defined property (3.1.17) and
limitations on the uncertainty of the property’s values falling within these limitations during the claim's
duration of applicability under stated conditions (3.1.11).
Note 1 to entry: The unambiguously defined property is called the claim's property.
Note 2 to entry: Uncertainties may also be associated with the duration of applicability and the stated conditions.
Note 3 to entry: A claim potentially contains the following:
— property of the system-of-interest (3.2.10);
— limitations on the value of the property associated with the claim (e.g. on its range);
— limitations on the uncertainty of the property value meeting its limitations;
— limitations on duration of claim's applicability;
— duration-related uncertainty;
— limitations on conditions associated with the claim;
— condition-related uncertainty.
Note 4 to entry: The term “limitations” is used to fit the many situations that can exist. Values can be a single value or
multiple single values, a range of values or multiple ranges of values, and can be multi-dimensional. The boundaries
of these limitations are sometimes not sharp, e.g., they can involve probability distributions and can be incremental.
3.1.11
condition
measurable qualitative or quantitative attribute (3.1.8) that is stipulated for a requirement (3.2.7) and that
indicates a circumstance or event under which a requirement applies
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.6]
3.1.12
constraint
externally imposed limitation on the system (3.2.8), its design, or implementation or on the process (3.2.4)
used to develop or modify a system
Note 1 to entry: A constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify
the design.
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.7]
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.1.13
critical property
property (3.1.17) that is agreed by primary stakeholders as having serious consequence (3.4.3)
3.1.14
dependability
ability to perform as and when required
Note 1 to entry: Dependability includes availability, reliability, recoverability, maintainability, and maintenance
support performance, and, in some cases, other characteristics such as durability, safety and security.
Note 2 to entry: Dependability is used as a collective term for the time-related quality characteristics of an item.
[SOURCE: IEC 60050-192:2015, 192-01-22]
3.1.15
evidence
data referred to by an argument that validates the given claim
Note 1 to entry: Evidence can include result of tests, inspections, simulations, audits.
Note 2 to entry: The role of the evidence is to support a demonstrable argument that the claim is valid.
3.1.16
inference
reasoning step that derives a claim (3.1.10) from a list of claims (premises) under a specified context
Note 1 to entry: The claim derived by inference is the conclusion, and the supported claims from which the inference
derives the conclusion are the premises.
Note 2 to entry: There are special inferences called obvious inferences. See 5.3.4 EXAMPLE 2.
3.1.17
property
attribute (3.1.8) of things
3.1.18
type
set of values, elements or items
3.1.19
undeveloped argument
placeholder argument to be replaced by a concrete argument
3.2 Terms related to system life cycles
3.2.1
approval authority
person (or persons) or organization (3.2.3) (or organizations), or both, responsible for approving activities,
artefacts and other aspects of the system (3.2.8) during its life cycle
Note 1 to entry: The approval authority may include multiple entities, e.g. individuals or organizations. These can
include different entitles with either different levels of approval or different areas of interest, or both.
Note 2 to entry: In two-party situations, the approval authority often rests with the acquirer. In regulatory situations,
the approval authority may be a third party such as a governmental organization or its agent. In other situations, for
example, the purchase of off-the-shelf products (3.2.6) developed by a single-party, the independence of the approval
authority can be a relevant issue to the acquirer.
3.2.2
design authority
person or organization (3.2.3) that is responsible for the design of the product (3.2.6)
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.2.3
organization
person or group of people that has its own functions with responsibilities, authorities, and relationships to
achieve its objectives
EXAMPLE Company, corporation, firm, enterprise, manufacturer, institution, charity, sole trader, association, or
parts or combination thereof.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.25]
3.2.4
process
set of interrelated or interacting activities that transforms inputs into outputs
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.27]
3.2.5
process view
description of how a specified purpose and set of outcomes can be achieved by employing the activities and
tasks of existing processes (3.2.4)
[SOURCE: ISO/IEC/IEEE 24774:2021, 3.15]
3.2.6
product
output of an organization (3.2.3) that can be produced without any transaction taking place between the
organization and the customer
Note 1 to entry: The dominant element of a product is that it is generally tangible.
[SOURCE: ISO 9000:2015, 3.7.6, modified — Notes 1 and 3 to entry have been removed.]
3.2.7
requirement
statement which translates or expresses a need and its associated constraints and conditions (3.1.11)
Note 1 to entry: Requirements exist at different levels in the system (3.2.8) structure.
Note 2 to entry: A requirement is an expression of one or more particular needs in a very specific, precise and
unambiguous manner.
Note 3 to entry: A requirement always relates to a system, software or service, or other item of interest.
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.19]
3.2.8
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product (3.2.6) or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun,
e.g. aircraft system. Alternatively, the word "system" is substituted simply by a context-dependent synonym (e.g.
aircraft), though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services and personnel required for operations and support to the degree
necessary for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.2.9
system element
discrete part of a system (3.2.8) that can be implemented to fulfil specified requirements (3.2.7)
EXAMPLE Hardware, software, data, humans, processes (3.2.4) [e.g. processes for providing service to users],
procedures [e.g. operator instructions], facilities, materials, and naturally occurring entities or any combination.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.47]
3.2.10
system-of-interest
system (3.2.8) whose life cycle is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48, modified — The abbreviated term "SoS" has been removed.]
3.3 Terms related to integrity level
3.3.1
integrity level
degree of confidence that the system-of-interest (3.2.10) meets the associated integrity level claim (3.3.3)
Note 1 to entry: A definition of “integrity” consistent with its use in “integrity level” has not been agreed in the relevant
communities. Hence, no separate definition of “integrity” is included in this document.
Note 2 to entry: An integrity level is different from the likelihood (3.4.11) that the integrity level claim is met but they
are closely related.
Note 3 to entry: The word “confidence” implies that the definition of integrity levels can be a subjective concept.
Note 4 to entry: In this document, integrity levels are defined in terms of risk (3.4.14) and hence cover safety, security,
economic and any other dimension of risk that is relevant to the system-of-interest.
3.3.2
integrity level assurance authority
independent person or organization (3.2.3) responsible for certifying compliance with the integrity level
requirements (3.3.5)
3.3.3
integrity level claim
proposition representing a requirement (3.2.7) on a risk reduction measure (3.4.16) identified in the risk
treatment (3.4.18)process (3.2.4) of the system-of-interest (3.2.10)
Note 1 to entry: In general, it is described in terms of requirements to avoid, control or mitigate the consequences
(3.4.3) of dangerous conditions (3.4.4), so as to provide a tolerable risk (3.4.21) if it is met.
Note 2 to entry: In the IEC 61508 series, the proposition that an E/E/PE safety-related system (3.2.8) satisfactorily
performs the specified safety functions under all stated conditions (3.1.11) can be regarded as an integrity level claim.
3.3.4
integrity level definition authority
person or organization (3.2.3) responsible for defining integrity levels (3.3.1) and integrity level
requirements (3.3.5)
3.3.5
integrity level requirements
set of requirements (3.2.7) that, when met, will provide a level of confidence in the associated integrity level
claim (3.3.3) commensurate with the associated integrity level (3.3.1)
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.4 Terms related to risks and dependability
3.4.1
adverse consequence
consequence (3.4.3) that results in a specified level of loss
Note 1 to entry: An adverse consequence results from the system-of-interest (3.2.10) being in a dangerous condition
(3.4.4) combined with the environment of the system (3.2.8) being in its worst-case state.
Note 2 to entry: Harm in ISO/IEC Guide 51 is an instance of an adverse consequence. The concept of adverse
consequences is introduced in order to cover not only harms in the safety context but also loss of assets in the security
context and any other losses.
3.4.2
attack
malicious action or interaction with the system (3.2.8) or its environment that has the potential to result in
a fault (3.4.8) or an error (3.4.6), and thereby possibly in a failure (3.4.7), or an adverse consequence (3.4.1)
3.4.3
consequence
outcome of an event affecting objectives
[SOURCE: ISO 31073:2022, 3.3.18, modified — Notes 1, 2 and 3 to entry have been removed.]
3.4.4
dangerous condition
state of a system (3.2.8) that, in combination with some states of the environment, will result in an adverse
consequence (3.4.1)
Note 1 to entry: A hazardous situation in ISO/IEC Guide 51 and IEC 61508-4 can be a dangerous condition. A threat
in the ISO/IEC/IEEE 15026 series is also an example of a dangerous condition. A concept of dangerous conditions is
introduced in order to cover not only hazardous situations in the safety context but also errors (3.4.6) in the reliability,
integrity, confidentiality or dependability (3.1.14) contexts and other states of a system which can lead to adverse
consequences.
Note 2 to entry: Occurrences of failures (3.4.7) in the context of reliability or as defined in IEC 61508-4 often but does
not always lead to dangerous conditions.
Note 3 to entry: A dangerous condition therefore has at least the following attributes (3.1.8):
a) the associated adverse consequences;
b) the trigger events that lead to the dangerous condition;
c) the trigger events that lead to the adverse consequences from the dangerous condition.
3.4.5
desirable consequence
positive consequence
consequence (3.4.3) associated with a benefit or gain or avoiding an adverse consequence (3.4.1)
3.4.6
error
discrepancy between a computed, observed or measured value or condition (3.1.11), and the true, specified
or theoretically correct value or condition
[SOURCE: IEC 60050-192:2015, 192-03-02, modified — Notes 1 and 2 to entry have been removed.]
3.4.7
failure
loss of ability to perform as required
Note 1 to entry: A failure of an item is an event that results in a fault (3.4.8) of that item.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
Note 2 to entry: Qualifiers, such as catastrophic, critical, major, minor, marginal and insignificant, can be used to
categorize failures according to the severity of consequences (3.4.3), the choice and definitions of severity criteria
depending upon the field of application.
Note 3 to entry: Qualifiers, such as misuse, mishandling and weakness, can be used to categorize failures according to
the cause of failure.
[SOURCE: IEC 60050-192:2015, 192-03-01]
3.4.8
fault
inability to perform as required, due to an internal state
Note 1 to entry: A fault of an item results from a failure (3.4.7), either of the item itself, or from a deficiency in an
earlier stage of the life cycle, such as specification, design, manufacture or maintenance.
Note 2 to entry: Qualifiers, such as specification, design, manufacture, maintenance or misuse, may be used to indicate
the cause of a fault.
Note 3 to entry: The type of fault may be associated with the type of associated failure, e.g. wear-out fault and wear-
out failure.
Note 4 to entry: The adjective “faulty” designates an item having one or more faults.
[SOURCE: IEC 60050-192:2015, 192-04-01, modified — The cross-reference to "latent fault" in note 1 to
entry has been removed.]
3.4.9
initial risk
estimated risk (3.4.14) before applying risk reduction measures (3.4.16)
3.4.10
level of risk
magnitude of a risk (3.4.14) or combination of risks, expressed in terms of the combination of consequences
(3.4.3) and their likelihood (3.4.11)
[SOURCE: ISO 31073:2022, 3.3.22]
3.4.11
likelihood
chance of something happening
[SOURCE: ISO 31073:2022, 3.3.16, modified — Notes 1 and 2 have been removed.]
3.4.12
property-of-interest
object whose loss is considered as a negative effect
Note 1 to entry: The concept of property-of-interest is introduced in order to characterize negative effects of
consequences (3.4.3).
Note 2 to entry: In the safety context, human lives and health can be property-of-interests.
Note 3 to entry: Assets in the security context, e.g. defined in ISO/IEC 15408-1, can be a property-of-interest.
3.4.13
residual risk
risk (3.4.14) remaining after risk treatment (3.4.18)
[SOURCE: ISO 31073:2022, 3.3.38, modified — Notes 1 and 2 have been removed.]
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.4.14
risk
effect of uncertainty on objectives
Note 1 to entry: An effect is a deviation from the expected. It can be– positive, negative or both. In this document the
focus is on negative deviations leading to adverse consequences (3.4.1).
Note 2 to entry: Risk is often characterized by reference to potential events and consequences (3.4.3), or a combination
of these.
Note 3 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including changes
in circumstances) and the associated likelihood (3.4.11) of occurrence. In this document risk is characterized as the
combination of the severity of the adverse consequence and the likelihood of an adverse consequence occurring.
Note 4 to entry: Objectives can have different aspects, such as financial, health and safety, and environmental goals
and can apply at different levels, such as strategic, organization-wide, project, product (3.2.6) and process (3.2.4).
Note 5 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or
knowledge of, an event, its consequence, or likelihood.
[SOURCE: ISO 31073:2022, 3.1.1, modified — Notes to entry have been reordered; information specific to
this document has been added in Notes 1 and 3 to entry.]
3.4.15
risk criteria
terms of reference against which the significance of a risk (3.4.14) is evaluated
[SOURCE: ISO 31073:2022, 3.3.6, modified — Notes 1 and 2 to entry have been removed.]
3.4.16
risk reduction measure
measure to reduce or mitigate risk (3.4.14)
Note 1 to entry: A typical risk reduction measure is a safety-related system (3.2.8) in the IEC 61508 series.
Note 2 to entry: Design, review and test are also risk reduction measures, as are hazards analysis incorporated in
the design.
3.4.17
risk source
element which alone or in combination has the intrinsic potential to give rise to risk (3.4.14)
Note 1 to entry: A hazard in ISO 31073 is an instance of a risk source.
Note 2 to entry: A fault (3.4.8), an error (3.4.6) or a failure (3.4.7) in the context of reliability can be a risk source.
Note 3 to entry: A threat in the context of security and a threat agent (3.4.20) and an adverse action defined in
ISO/IEC 15408-1 can be a risk source.
[SOURCE: ISO 31073:2022, 3.3.10, modified —Notes 1, 2 and 3 to entry have been added.]
3.4.18
risk treatment
process (3.2.4) to eliminate risk (3.4.14) or reduce it to a tolerable level
[SOURCE: ISO 31073:2022, 3.3.32, modified — The words “modify risk” have been replaced with “eliminate
risk or reduce it to a tolerable level”; notes 1, 2 and 3 to entry have been removed.]
3.4.19
systematic failure
failure (3.4.7) that consistently occurs under particular conditions (3.1.11) of handling, storage or use
Note 1 to entry: A systematic failure can be reproduced by deliberately applying the same conditions, although not all
reproducible failures are systematic.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
Note 2 to entry: The cause of a systematic failure originates in the specification, design, manufacture, installation,
operation or maintenance of the item.
[SOURCE: IEC 60050-192:2015, 192-03-10]
3.4.20
threat agent
entity that can adversely act on property-of-interest (3.4.12)
3.4.21
tolerable risk
level of risk (3.4.10) which is accepted in a given context based on the current values of society
Note 1 to entry: A tolerable risk is sometimes called an acceptable risk, for example, see ISO/IEC/IEEE 16085 and
ISO 14971. The general risk management standards ISO 31073 and ISO 31000 use both phrases without explicit
definitions.
[SOURCE: ISO/IEC Guide 51:2014, 3.15, modified — Note 1 to entry has been replaced by a new one.]
3.4.22
violation
behaviour, act or event deviating from a system’s (3.2.8) desired property or claim (3.1.10) of interest
Note 1 to entry: In the area of safety, the term “violation” is used to refer to a deliberate human contravention of a
procedure or rule.
4 Basic concepts
4.1 General
This clause covers the concepts and vocabulary fundamental to the ISO/IEC/IEEE 15026 series.
4.2 Assurance
The ISO/IEC/IEEE 15026 series uses a specific definition for assurance as being grounds for justified
confidence. Generally, stakeholders require grounds for justified confidence prior to depending on a system,
especially a system involving complexity, novelty or technology with a history of problems (e.g. software).
The greater the degree of dependence, the greater the demand for strong grounds for confidence. The
appropriate valid arguments and evidence establish a rational basis for justified confidence in the relevant
claims about the system’s properties. These properties may include such aspects as future costs, behaviour
and consequences. Throughout the life cycle, adequate grounds justify decisions related to ensuring the
design and production of an adequate system and to be able to place reliance on that system.
Assurance i
...
ISO/IEC/IEEE FDIS 15026-1:2024(en)
ISO/IEC /JTC 1/SC 7 N9752
Secretariat: BIS
Date: 2025-07-04-15
Systems and software engineering — Systems and software
assurance —
Part 1: Concepts
Vocabulary and vocabularyconcepts
Ingénierie des systèmes et du logiciel — Assurance des systèmes et du logiciel — —
Partie 1: ConceptsVocabulaire et vocabulaireconcepts
FDIS stage
ISO/IEC/IEEE CDFDIS 15026–-1
:20xx(E:2025(en)
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
at the address below or ISO'sISO’s member body in the country of the requester.
ISO Copyright Officecopyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
Email: E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland.
© ISO/IEC/IEEE 20xx 2025 – All rights reserved
ii
ISO/IEC/IEEE FDIS 15026-1:2025(en)
Contents Page
Foreword . iv
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Terms related to assurance . 1
3.2 Terms related to system life cycles . 5
3.3 Terms related to integrity level . 6
3.4 Terms related to risks and dependability . 7
4 Basic concepts . 11
4.1 General . 11
4.2 Assurance . 11
4.3 Stakeholders . 12
4.4 System and product . 12
4.5 Property . 12
4.6 Uncertainty and confidence . 13
4.7 Conditions and initiating events . 13
4.8 Consequences . 14
5 Using multiple parts of the ISO/IEC/IEEE 15026 series . 15
5.1 General . 15
5.2 Initial usage guidance. 15
5.3 Relationships among parts of the ISO/IEC/IEEE 15026 series . 15
5.4 Authorities . 15
6 The ISO/IEC/IEEE 15026 series and the assurance case . 16
6.1 General . 16
6.2 Justification of method of reasoning . 16
6.3 Means of obtaining and managing evidence . 17
6.4 Certifications and accreditations . 18
7 The ISO/IEC/IEEE 15026 series and integrity levels . 18
7.1 General . 18
7.2 Risk analysis . 18
8 The ISO/IEC/IEEE 15026 series and the life cycle . 19
8.1 General . 19
8.2 Assurance activities in the life cycle . 20
Bibliography . 21
IEEE notices and abstract . 28
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
iii
ISO/IEC/IEEE CDFDIS 15026–-1
:20xx(E:2025(en)
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 the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards
through a consensus development process, approved by the American National Standards Institute, which
brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE
administers the process and establishes rules to promote fairness in the consensus development process, the
IEEE does not independently evaluate, test, or verify the accuracy of any of the information 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.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 15026-1:2019), which has been
technically revised.
The main changes are as follows:
© ISO/IEC/IEEE 20xx 2025 – All rights reserved
iv
ISO/IEC/IEEE FDIS 15026-1:2025(en)
— — definitions of terms introduced in other parts of the ISO/IEC/IEEE 15026 series have been added or
modified;
— — definitions of terms whose definitions were sourced from ISO/IEC 15288 and ISO/IEC/IEEE 24774
have been updated.
A list of all parts in the ISO/IEC/IEEE 15026 series can be found on the ISO website and IEC websites.
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 2025, © /IEEE 2025 – All rights reserved
v
ISO/IEC/IEEE CDFDIS 15026–-1
:20xx(E:2025(en)
Introduction
Software and systems assurance and closely related fields share concepts but have different vocabularies and
perspectives. This document provides an unambiguous use of vocabulary for systems and software assurance
and a unifying set of underlying concepts across these various fields. It provides a basis for elaboration,
discussion and recording agreement and rationale regarding concepts and the vocabulary used uniformly
across the ISO/IEC/IEEE 15026. series.
Clause 4Clause 4 of this document covers basic concepts such as assurance, stakeholders, systems and
products, property, uncertainty and confidence, conditions and initial events, and consequence.
Clause 5Clause 5 covers some issues of which users of ISO/IEC/IEEE 15026-2, ISO/IEC/IEEE 15026-3 and
ISO/IEC/IEEE 15026-4 should be initially aware (5.2). Clause 6(5.2). Clause 6, Clause 7, Clause 7 and
Clause 8Clause 8, respectively, cover concepts and relevant to users of ISO/IEC/IEEE 15026-2,
ISO/IEC/IEEE 15026-3 and ISO/IEC/IEEE 15026-4, respectively; also, users of one of these parts can benefit
from the clauses for other parts.
The essential concepts introduced by the ISO/IEC/IEEE 15026 series are the claims in an assurance case and
the support of claims in terms of argument and evidence. These claims are in the context of assurance for
properties of systems and software within life cycle processes for the system or software product.
Potential users of the ISO/IEC/IEEE 15026 series are developers and maintainers of assurance cases and those
who wish to develop, sustain, evaluate or acquire a system that possesses requirements for specific properties
in such a way as to be more certain of those properties and their requirements. The ISO/IEC/IEEE 15026
series uses concepts and vocabulary consistent with ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288 and
generally consistent with the standards on Systems and software Quality Requirements and Evaluation
(SQuaRE) developed by JTC 1/SC 7, but the concepts and vocabulary provided by the ISO/IEC/IEEE 15026 (all
parts)series can differ from those to which the potential user is accustomed. This document attempts to clarify
these differences.
The ISO/IEC/IEEE 15026 series is made up of the following parts.
— — ISO/IEC/IEEE 15026-1 explains concepts and terms as a basis for all parts of the ISO/IEC/IEEE 15026
series.
— — ISO/IEC/IEEE 15026-2 includes requirements on the structure of the assurance case.
— — ISO/IEC/IEEE 15026-3 relates integrity levels to the assurance case and includes requirements for
their use with and without an assurance case.
— — ISO/IEC/IEEE 15026-4 provides guidance and recommendations for assurance of a selected claim
about the system-of-interest by achieving the claim and showing the achievement. The guidance and
recommendations are given in a system assurance process view on top of ISO/IEC/IEEE 15288 and a
software assurance process view on top of ISO/IEC/IEEE 12207.
The assurance case is relevant to a greater or lesser extent in all parts of the ISO/IEC/IEEE 15026 series,
although ISO/IEC/IEEE 15026-4 discusses achieving the claim and showing the achievement of the claim
whether or not such “showing” is contained in an artefact specifically called an “assurance case”.
© ISO/IEC/IEEE 20xx 2025 – All rights reserved
vi
ISO/IEC/IEEE FDIS 15026-1:2025(en)
ISO/IEC/IEEE 15026-2 concentrates on the contents and structure of the assurance case.
ISO/IEC/IEEE 15026-3 relates integrity levels and assurance cases by describing how integrity levels and
assurance cases can work together, especially in the definition of specifications for integrity levels or by using
integrity levels within a portion of an assurance case. This relationship is governed by the degree of risk and
dependencies in the system.
ISO/IEC/IEEE 15026-4 includes assurance-related guidance and recommendations for activities across the
life cycle processes including activities that extend beyond those directly related to an assurance case, e.g.
project planning for assurance-related considerations.
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
vii
FINAL DRAFT International Standard ISO/IEC/IEEE FDIS 15026-1:2024(en)
Systems and software engineering — Systems and software
assurance — Part 1: Concepts and vocabulary
Part 1:
Vocabulary and concepts
1 Scope
This document defines assurance-related terms and establishes an organized set of concepts to form a basis
for shared understanding in the field of assurance. It benefits users of ISO/IEC/IEEE 15026-2, ISO/IEC/IEEE
15026-3 and ISO/IEC/IEEE 15026-4.
ConceptsVocabulary and vocabularyconcepts for assurance of a service being operated and managed on an
ongoing basis is not covered in this document.
While essential to assurance practice, details regarding exactly how to measure, demonstrate or analyse
particular properties are not covered. These are the subjects of more specialized standards some of which are
included in the Bibliography.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
ISO, IEC and IEEE maintain terminologicalterminology 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 https://ieeexplore.ieee.org/xpls/dictionary.jsp
NOTE Definitions for other system For additional terms and definitions in the field of systems and
software engineering terms can be found in , see ISO/IEC/IEEE 24765, availablewhich is published periodically as a
“snapshot” of the SEVOCAB (Systems and software engineering vocabulary) database and is publicly accessible at
https://www.computer.org/sevocab.
3.1 Terms related to assurance
3.1.1 3.1.1
assurance
grounds for justified confidence that a claim (3.1.10(3.1.10)) has been or will be achieved
Note 1 to entry: By definition, assurance is about a claim.
Note 2 to entry: The claim can be a conjunction of more than one claim.
© ISO/IEC 2024, © IEEE 2024 – All rights reserved
ISO/IEC/IEEE DISFDIS 15026–-1:20xx(E2025(en)
3.1.2 3.1.2
assurance argument
artefact that links tangible evidence (3.1.15) and assumptions to provide a convincing and valid argument of a
claim (3.1.10(3.1.10)) under a given context
Note 1 to entry: An assurance argument provides the reasoning that connects the evidence (and assumptions) to the
claim. It explains 'why' the evidence supports the claim and how the evidence is relevant.
Note 2 to entry: An argument is valid if and only if all of its premises being true implies that its conclusion is true.
3.1.3 3.1.3
assurance case
auditable artefact that provides a convincing and sound argument for a claim (3.1.10(3.1.10)) on the basis of
tangible evidence (3.1.15) under a given context
Note 1 to entry: An argument is sound if and only it is valid and contains only true premises.
Note 2 to entry: Premises of an argument are propositions, and all propositions are either true or false.
Note 2 to entry: An argument is sound only if it is valid and contains only true premises.
Note 3 to entry: An argument is not sound if it is valid but contains some false premises.
3.1.4 3.1.4
assurance case report
auditable artefact that provides the claim (3.1.10(3.1.10)) of an assurance case (3.1.3(3.1.3)) and a complete
index of the argument and evidence (3.1.15) of the assurance case such that the assurance case of interest can
be assembled from the index
Note 1 to entry: An assurance case report is mapped to the report field. An assurance case report is an introduction to
the assurance case. Its content varies from one case to another. For simple assurance cases, a report can be superfluous.
For larger or more complex assurance cases the report can include a system (3.2.8(3.2.8)) description, some of the
argument and its supporting evidence e.g. the higher-level arguments and their supporting evidence.
Note 2 to entry: Assurance case reports are often issued as periodic updates to the assurance case at pre-agreed points
such as at the end of a life cycle stage. They report on results of assurance activities done so far, an assessment of overall
progress and a review of assurance activities’ performance. Assurance case reports can be used at decision gates for stage
exit/entry by suppliers and for project monitoring by acquirers.
3.1.5 3.1.5
assurance claim
claim (3.1.10(3.1.10)) for which assurance (3.1.1(3.1.1)) is considered
3.1.6 3.1.6
assurance information
information including a claim (3.1.10(3.1.10)) about a system (3.2.8(3.2.8),), evidence (3.1.15) supporting the
claim, an argument showing how the evidence supports the achievement of the claim, and the context for these
items
Note 1 to entry: The sub-claims included in the argument of assurance information can be about the life cycle of the
system-of-interest (3.2.10(3.2.10)) when, for example, the top-level claim implies continuous achievement of some
property (3.1.17(3.1.17).).
Note 2 to entry: ISO/IEC/IEEE 15026-2 specifies assurance cases (3.1.3(3.1.3)) that documents assurance information.
3.1.7 3.1.7
assurance objective
purpose of achievement of the assurance claim (3.1.5(3.1.5))
© © ISO/IEC/IEEE 20xx 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
Note 1 to entry: Assurance objectives determine the required degree of integrity level (3.3.1(3.3.1)) and permissible
uncertainty in the assurance information (3.1.6(3.1.6).).
3.1.8 3.1.8
attribute
inherent property (3.1.17(3.1.17)) or characteristic of an entity that can be distinguished quantitatively or
qualitatively by human or automated means
Note 1 to entry: ISO 9000 distinguishes two types of attributes: a permanent characteristic existing inherently in
something; and an assigned characteristic of a product (3.2.6(3.2.6),), process (3.2.4(3.2.4),), or system (3.2.8(3.2.8)) (e.g.
the price of a product, the owner of a product).
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.2]
3.1.9 3.1.9
basic assumption
assumption in a collection of claims (3.1.10(3.1.10)) shared by assurance cases (3.1.3(3.1.3)) in a specific field
Note 1 to entry: Such a collection corresponds to a set of axioms in formal system in logic.
3.1.10 3.1.10
claim
true-false statement about the limitations on the values of an unambiguously defined property (3.1.17(3.1.17))
and limitations on the uncertainty of the property’s values falling within these limitations during the claim's
duration of applicability under stated conditions (3.1.11(3.1.11).).
Note 1 to entry: The unambiguously defined property is called the claim's property.
Note 2 to entry: Uncertainties may also be associated with the duration of applicability and the stated conditions.
Note 3 to entry: A claim potentially contains the following:
— — property of the system-of-interest (3.2.10(3.2.10););
— — limitations on the value of the property associated with the claim (e.g. on its range);
— — limitations on the uncertainty of the property value meeting its limitations;
— — limitations on duration of claim's applicability;
— — duration-related uncertainty;
— — limitations on conditions associated with the claim;
— — condition-related uncertainty.
Note 4 to entry: The term “limitations” is used to fit the many situations that can exist. Values can be a single value or
multiple single values, a range of values or multiple ranges of values, and can be multi-dimensional. The boundaries of
these limitations are sometimes not sharp, e.g., they can involve probability distributions and can be incremental.
3.1.11 3.1.11
condition
(3.1.8)) that is stipulated for a requirement
measurable qualitative or quantitative attribute (3.1.8
(3.2.7(3.2.7)) and that indicates a circumstance or event under which a requirement applies
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.6]
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
ISO/IEC/IEEE DISFDIS 15026–-1:20xx(E2025(en)
3.1.12 3.1.12
constraint
externally imposed limitation on the system (3.2.8(3.2.8),), its design, or implementation or on the process
(3.2.4(3.2.4)) used to develop or modify a system
Note 1 to entry: A constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify
the design.
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.7]
3.1.13 3.1.13
critical property
property (3.1.17(3.1.17)) that is agreed by primary stakeholders as having serious consequence (3.4.3(3.4.3))
3.1.14 3.1.14
dependability
ability to perform as and when required
Note 1 to entry: Dependability includes availability, reliability, recoverability, maintainability, and maintenance support
performance, and, in some cases, other characteristics such as durability, safety and security.
Note 2 to entry: Dependability is used as a collective term for the time-related quality characteristics of an item.
[SOURCE: IEC 60050-192:2015, 192-01-22]
3.1.15 3.1.15
evidence
data referred to by an argument that validates the given claim
Note 1 to entry: Evidence can include result of tests, inspections, simulations, audits.
Note 2 to entry: The role of the evidence is to support a demonstrable argument that the claim is valid.
3.1.16 3.1.16
inference
reasoning step that derives a claim (3.1.10(3.1.10)) from a list of claims (premises) under a specified context
Note 1 to entry: The claim derived by inference is the conclusion, and the supported claims from which the inference
derives the conclusion are the premises.
Note 2 to entry: There are special inferences called obvious inferences. See 5.3.4 EXAMPLE 2.
3.1.17 3.1.17
property
attribute (3.1.8(3.1.8)) of things
3.1.18 3.1.18
type
set of values, elements or items
3.1.19 3.1.19
undeveloped argument
placeholder argument to be replaced by a concrete argument
© © ISO/IEC/IEEE 20xx 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.2 Terms related to system life cycles
3.2.1 3.2.1
approval authority
person (or persons) or organization (3.2.3(3.2.3)) (or organizations), or both, responsible for approving
activities, artefacts and other aspects of the system (3.2.8(3.2.8)) during its life cycle
Note 1 to entry: The approval authority may include multiple entities, e.g. individuals or organizations. These can include
different entitles with either different levels of approval or different areas of interest, or both.
Note 2 to entry: In two-party situations, the approval authority often rests with the acquirer. In regulatory situations, the
approval authority may be a third party such as a governmental organization or its agent. In other situations, for example,
the purchase of off-the-shelf products (3.2.6(3.2.6)) developed by a single-party, the independence of the approval
authority can be a relevant issue to the acquirer.
3.2.2 3.2.2
design authority
person or organization (3.2.3(3.2.3)) that is responsible for the design of the product (3.2.6(3.2.6))
3.2.3 3.2.3
organization
person or group of people that has its own functions with responsibilities, authorities, and relationships to
achieve its objectives
EXAMPLE Company, corporation, firm, enterprise, manufacturer, institution, charity, sole trader, association, or
parts or combination thereof.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.25]
3.2.4 3.2.4
process
set of interrelated or interacting activities that transforms inputs into outputs
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.27]
3.2.5 3.2.5
process view
description of how a specified purpose and set of outcomes can be achieved by employing the activities and
tasks of existing processes (3.2.4(3.2.4))
[SOURCE: ISO/IEC/IEEE 24774:2021, 3.15]
3.2.6 3.2.6
product
output of an organization (3.2.3(3.2.3)) that can be produced without any transaction taking place between
the organization and the customer
Note 1 to entry: The dominant element of a product is that it is generally tangible.
[SOURCE: ISO 9000:2015, 3.7.6, modified — Notes 1 and 3 to entry have been removed.]
3.2.7 3.2.7
requirement
statement which translates or expresses a need and its associated constraints and conditions (3.1.11(3.1.11))
Note 1 to entry: Requirements exist at different levels in the system (3.2.8(3.2.8)) structure.
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
ISO/IEC/IEEE DISFDIS 15026–-1:20xx(E2025(en)
Note 2 to entry: A requirement is an expression of one or more particular needs in a very specific, precise and
unambiguous manner.
Note 3 to entry: A requirement always relates to a system, software or service, or other item of interest.
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.19]
3.2.8 3.2.8
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product (3.2.6(3.2.6)) or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g.
aircraft system. Alternatively, the word "system" is substituted simply by a context-dependent synonym (e.g. aircraft),
though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services and personnel required for operations and support to the degree necessary
for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]
3.2.9 3.2.9
system element
discrete part of a system (3.2.8(3.2.8)) that can be implemented to fulfil specified requirements (3.2.7(3.2.7))
EXAMPLE Hardware, software, data, humans, processes (3.2.4(3.2.4)) [e.g. processes for providing service to users],
procedures [e.g. operator instructions], facilities, materials, and naturally occurring entities or any combination.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.47]
3.2.10 3.2.10
system-of-interest
system (3.2.8(3.2.8)) whose life cycle is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48, modified — The abbreviated term "SoS" has been removed.]
3.3 Terms related to integrity level
3.3.1 3.3.1
integrity level
degree of confidence that the system-of-interest (3.2.10(3.2.10)) meets the associated integrity level claim
(3.3.3(3.3.3))
Note 1 to entry: A definition of “integrity” consistent with its use in “integrity level” has not been agreed in the relevant
communities. Hence, no separate definition of “integrity” is included in this document.
Note 2 to entry: An integrity level is different from the likelihood (3.4.11(3.4.11)) that the integrity level claim is met but
they are closely related.
Note 3 to entry: The word “confidence” implies that the definition of integrity levels can be a subjective concept.
Note 4 to entry: In this document, integrity levels are defined in terms of risk (3.4.14(3.4.14)) and hence cover safety,
security, economic and any other dimension of risk that is relevant to the system-of-interest.
© © ISO/IEC/IEEE 20xx 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.3.2 3.3.2
integrity level assurance authority
independent person or organization (3.2.3(3.2.3)) responsible for certifying compliance with the integrity
level requirements (3.3.5(3.3.5))
3.3.3 3.3.3
integrity level claim
proposition representing a requirement (3.2.7(3.2.7)) on a risk reduction measure (3.4.16(3.4.16)) identified
in the risk treatment (3.4.18(3.4.18) )process (3.2.4(3.2.4)) of the system-of-interest (3.2.10(3.2.10))
Note 1 to entry: In general, it is described in terms of requirements to avoid, control or mitigate the consequences
(3.4.3(3.4.3)) of dangerous conditions (3.4.4(3.4.4),), so as to provide a tolerable risk (3.4.21(3.4.21)) if it is met.
Note 2 to entry: In the IEC 61508 series, the proposition that an E/E/PE safety-related system (3.2.8(3.2.8)) satisfactorily
performs the specified safety functions under all stated conditions (3.1.11(3.1.11)) can be regarded as an integrity level
claim.
3.3.4 3.3.4
integrity level definition authority
person or organization (3.2.3(3.2.3)) responsible for defining integrity levels (3.3.1(3.3.1)) and integrity level
requirements (3.3.5(3.3.5))
3.3.5 3.3.5
integrity level requirements
set of requirements (3.2.7(3.2.7)) that, when met, will provide a level of confidence in the associated integrity
level claim (3.3.3(3.3.3)) commensurate with the associated integrity level (3.3.1(3.3.1))
3.4 Terms related to risks and dependability
3.4.1 3.4.1
adverse consequence
consequence (3.4.3(3.4.3)) that results in a specified level of loss
Note 1 to entry: An adverse consequence results from the system-of-interest (3.2.10(3.2.10)) being in a dangerous
condition (3.4.4(3.4.4)) combined with the environment of the system (3.2.8(3.2.8)) being in its worst-case state.
Note 2 to entry: Harm in ISO/IEC Guide 51 is an instance of an adverse consequence. The concept of adverse
consequences is introduced in order to cover not only harms in the safety context but also loss of assets in the security
context and any other losses.
3.4.2 3.4.2
attack
malicious action or interaction with the system (3.2.8(3.2.8)) or its environment that has the potential to result
in a fault (3.4.8(3.4.8)) or an error (3.4.6(3.4.6),), and thereby possibly in a failure (3.4.7(3.4.7),), or an adverse
consequence (3.4.1(3.4.1))
3.4.3 3.4.3
consequence
outcome of an event affecting objectives
[SOURCE: ISO 31073:2022, 3.3.18, modified — Notes 1, 2 and 3 to entry have been removed.]
3.4.4 3.4.4
dangerous condition
state of a system (3.2.8(3.2.8)) that, in combination with some states of the environment, will result in an
adverse consequence (3.4.1(3.4.1))
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
ISO/IEC/IEEE DISFDIS 15026–-1:20xx(E2025(en)
Note 1 to entry: A hazardous situation in ISO/IEC Guide 51 and IEC 61508-4 can be a dangerous condition. A threat in the
ISO/IEC/IEEE 15026 (all parts)series is also an example of a dangerous condition. A concept of dangerous conditions is
introduced in order to cover not only hazardous situations in the safety context but also errors (3.4.6(3.4.6)) in the
reliability, integrity, confidentiality or dependability (3.1.14(3.1.14)) contexts and other states of a system which can lead
to adverse consequences.
Note 2 to entry: Note 2 to entry: Occurrences of failures (3.4.7(3.4.7)) in the context of reliability or as defined in IEC
61508-4 often but does not always lead to dangerous conditions.
Note 3 to entry: A dangerous condition therefore has at least the following attributes (3.1.8(3.1.8):):
a) a) the associated adverse consequences;
b) b) the trigger events that lead to the dangerous condition;
c) c) the trigger events that lead to the adverse consequences from the dangerous condition.
3.4.5 3.4.5
desirable consequence
positive consequence
consequence (3.4.3(3.4.3)) associated with a benefit or gain or avoiding an adverse consequence (3.4.1(3.4.1))
3.4.6 3.4.6
error
discrepancy between a computed, observed or measured value or condition (3.1.11(3.1.11),), and the true,
specified or theoretically correct value or condition
[SOURCE: IEC 60050-192:2015, 192-03-02, modified — Notes 1 and 2 to entry have been removed.]
3.4.7 3.4.7
failure
loss of ability to perform as required
Note 1 to entry: A failure of an item is an event that results in a fault (3.4.8(3.4.8)) of that item.
Note 2 to entry: Qualifiers, such as catastrophic, critical, major, minor, marginal and insignificant, can be used to
categorize failures according to the severity of consequences (3.4.3(3.4.3),), the choice and definitions of severity criteria
depending upon the field of application.
Note 3 to entry: Qualifiers, such as misuse, mishandling and weakness, can be used to categorize failures according to the
cause of failure.
[SOURCE: IEC 60050-192:2015, 192-03-01]
3.4.8 3.4.8
fault
inability to perform as required, due to an internal state
Note 1 to entry: A fault of an item results from a failure (3.4.7(3.4.7),), either of the item itself, or from a deficiency in an
earlier stage of the life cycle, such as specification, design, manufacture or maintenance.
Note 2 to entry: Qualifiers, such as specification, design, manufacture, maintenance or misuse, may be used to indicate
the cause of a fault.
Note 3 to entry: The type of fault may be associated with the type of associated failure, e.g. wear-out fault and wear-out
failure.
Note 4 to entry: The adjective “faulty” designates an item having one or more faults.
© © ISO/IEC/IEEE 20xx 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
[SOURCE: IEC 60050-192:2015, 192-04-01, Note 1 modified]modified — The cross-reference to "latent fault"
in note 1 to entry has been removed.]
3.4.9 3.4.9
initial risk
estimated risk (3.4.14(3.4.14)) before applying risk reduction measures (3.4.16(3.4.16))
3.4.10 3.4.10
level of risk
magnitude of a risk (3.4.14(3.4.14)) or combination of risks, expressed in terms of the combination of
consequences (3.4.3(3.4.3)) and their likelihood (3.4.11(3.4.11))
[SOURCE: ISO 31073:2022, 3.3.22]
3.4.11 3.4.11
likelihood
chance of something happening
[SOURCE: ISO 31073:2022, 3.3.16, modified — Notes 1 and 2 have been removed.]
3.4.12 3.4.12
property-of-interest
object whose loss is considered as a negative effect
Note 1 to entry: The concept of property-of-interest is introduced in order to characterize negative effects of
consequences (3.4.3(3.4.3).).
Note 2 to entry: In the safety context, human lives and health can be property-of-interests.
Note 3 to entry: Assets in the security context, e.g. defined in ISO/IEC 15408-1, can be a property-of-interest.
3.4.13 3.4.13
residual risk
risk (3.4.14(3.4.14)) remaining after risk treatment (3.4.18(3.4.18))
[SOURCE: ISO 31073:2022, 3.3.38, modified — Notes 1 and 2 have been removed.]
3.4.14 3.4.14
risk
effect of uncertainty on objectives
Note 1 to entry: An effect is a deviation from the expected. It can be– positive, negative or both. In this document the focus
is on negative deviations leading to adverse consequences (3.4.1(3.4.1).).
Note 2 to entry: Risk is often characterized by reference to potential events and consequences (3.4.3(3.4.3),), or a
combination of these.
Note 3 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including changes in
circumstances) and the associated likelihood (3.4.11(3.4.11)) of occurrence. In this document risk is characterized as the
combination of the severity of the adverse consequence and the likelihood of an adverse consequence occurring.
Note 4 to entry: Objectives can have different aspects, such as financial, health and safety, and environmental goals and
can apply at different levels, such as strategic, organization-wide, project, product (3.2.6(3.2.6)) and process
(3.2.4(3.2.4).).
Note 5 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge
of, an event, its consequence, or likelihood.
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
ISO/IEC/IEEE DISFDIS 15026–-1:20xx(E2025(en)
[SOURCE: ISO 31073:2022, 3.1.1, modified — Notes to entry have been reordered; information specific to this
document has been added in Notes 1 and 3 to entry.]
3.4.15 3.4.15
risk criteria
terms of reference against which the significance of a risk (3.4.14(3.4.14)) is evaluated
[SOURCE: ISO 31073:2022, 3.3.6, modified — Notes 1 and 2 to enteryentry have been removed.]
3.4.16 3.4.16
risk reduction measure
measure to reduce or mitigate risk (3.4.14(3.4.14))
Note 1 to entry: A typical risk reduction measure is a safety-related system (3.2.8(3.2.8)) in the IEC 61508 series.
Note 2 to entry: Design, review and test are also risk reduction measures, as are hazards analysis incorporated in the
design.
3.4.17 3.4.17
risk source
element which alone or in combination has the intrinsic potential to give rise to risk (3.4.14(3.4.14))
Note 1 to entry: A hazard in ISO 31073 is an instance of a risk source.
Note 2 to entry: A fault (3.4.8(3.4.8),), an error (3.4.6(3.4.6)) or a failure (3.4.7(3.4.7)) in the context of reliability can be
a risk source.
Note 3 to entry: A threat in the context of security and a threat agent (3.4.20(3.4.20)) and an adverse action defined in
ISO/IEC 15408-1 can be a risk source.
[SOURCE: ISO 31073:2022, 3.3.10, modified —Notes 1, 2 and 3 to entry have been added.]
3.4.18 3.4.18
risk treatment
process (3.2.4(3.2.4)) to eliminate risk (3.4.14(3.4.14)) or reduce it to a tolerable level
[SOURCE: ISO 31073:2022, 3.3.32, modified — The words “modify risk” have been replaced with “eliminate
risk or reduce it to a tolerable level”; notes 1, 2 and 3 to entry have been removed.]
3.4.19 3.4.19
systematic failure
failure (3.4.7(3.4.7)) that consistently occurs under particular conditions (3.1.11(3.1.11)) of handling, storage
or use
Note 1 to entry: A systematic failure can be reproduced by deliberately applying the same conditions, although not all
reproducible failures are systematic.
Note 2 to entry: The cause of a systematic failure originates in the specification, design, manufacture, installation,
operation or maintenance of the item.
[SOURCE: IEC 60050-192:2015, 192-03-10]
3.4.20 3.4.20
threat agent
entity that can adversely act on property-of-interest (3.4.12(3.4.12))
© © ISO/IEC/IEEE 20xx 2025 – All rights reserved
ISO/IEC/IEEE FDIS 15026-1:2025(en)
3.4.21 3.4.21
tolerable risk
level of risk (3.4.10(3.4.10)) which is accepted in a given context based on the current values of society
Note 1 to entry: A tolerable risk is sometimes called an acceptable risk, for example, see ISO/IEC/IEEE 16085 and
ISO 14971. The general risk management standards ISO 31073 and ISO 31000 use both phrases without explicit
definitions.
[SOURCE: ISO/IEC Guide 51:2014, 3.15, modified — Note 1 to entry has been replaced by a new one.]
3.4.22 3.4.22
violation
behaviour, act or event deviating from a system’s (3.2.8(3.2.8)) desired property or claim (3.1.10(3.1.10)) of
interest
Note 1 to entry: In the area of safety, the term “violation” is used to refer to a deliberate human contravention of a
procedure or rule.
4 Basic concepts
4.1 General
This clause covers the concepts and vocabulary fundamental to the ISO/IEC/IEEE 15026 series.
4.2 Assurance
The ISO/IEC/IEEE 15026 series uses a specific definition for assurance as being grounds for justified
confidence. Generally, stakeholders require grounds for justified confidence prior to depending on a system,
especially a system involving complexity, novelty or technology with a history of problems (e.g. software). The
greater the degree of dependence, the greater the demand for strong grounds for confidence. The appropriate
valid arguments and evidence establish a rational basis for justified confidence in the relevant claims about
the system’s properties. These properties may include such aspects as future costs, behaviour and
consequences. Throughout the life cycle, adequate grounds justify decisions related to ensuring the design and
production of an adequate system and to be able to place reliance on that system.
Assurance is a term whose usage varies among the communities who use the term. However, all usage relates
to placing limitations on or reducing uncertainty in such things as measurements, observations, estimations,
predictions, information, inferences or effects of unknowns with the ultimate objective of either achieving or
showing a claim, or both. Such a reduction in uncertainty can provide an improved basis for justified
confidence. Even if the estimate of a property’s value remains unchanged, the effort spent in reducing
uncertainty about its value can often be cost-effective since the resulting reduced uncertainty improves the
basis for decision-making.
Assurance justifies the confidence that:
a) a) the system or software, as specified, meets real-world needs and expectations;
b) b) the as-built and operated system meets the specifications; or
c) c) both a) and b).
Specifications may be representations of either static or dynamic aspects of the system, or both. Specifications
often include descriptions of capability, functionality, behaviour, structure, service and responsibility
including time-related and
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.