ISO/IEC/IEEE 15026-1:2019

INTERNATIONAL ISO/IEC/
STANDARD IEEE
15026-1
First edition
2019-03
Systems and software engineering —
Systems and software assurance —
Part 1:
Concepts and vocabulary
Ingénierie des systèmes et du logiciel — Assurance des systèmes et du
logiciel —
Partie 1: Concepts et vocabulaire
Reference number
©
ISO/IEC 2019
©
IEEE 2019
© ISO/IEC 2019
© IEEE 2019
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
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2019 – All rights reserved
ii © IEEE 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Terms related to assurance and properties . 2
3.2 Terms related to product and process . 3
3.3 Terms related to integrity level . 4
3.4 Terms related to conditions and consequences . 6
3.5 Terms related to organization. 8
4 Organization of this document . 9
5 Basic concepts . 9
5.1 General . 9
5.2 Assurance . 9
5.3 Stakeholders .10
5.4 System and product .10
5.5 Property .10
5.5.1 General.10
5.5.2 Properties as behaviours .11
5.6 Uncertainty and confidence .11
5.7 Conditions and initiating events .11
5.8 Consequences.12
6 Using multiple parts of ISO/IEC/IEEE 15026 .12
6.1 General .12
6.2 Initial usage guidance .13
6.3 Relationships among parts of ISO/IEC/IEEE 15026 .13
6.4 Authorities .14
7 ISO/IEC/IEEE 15026 (all parts) and the assurance case .14
7.1 General .14
7.2 Justification of method of reasoning .15
7.3 Means of obtaining and managing evidence .15
7.4 Certifications and accreditations .16
8 ISO/IEC/IEEE 15026 (all parts) and integrity levels .16
8.1 General .16
8.2 Risk analysis .17
9 ISO/IEC/IEEE 15026 (all parts) and the life cycle .17
9.1 General .17
9.2 Assurance activities in the life cycle .18
10 Summary .18
Bibliography .19
IEEE notices and abstract .28
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – 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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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 ISO documents should be noted. This document was drafted in accordance with the
rules given in the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
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.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents).
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.
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 first edition cancels and replaces ISO/IEC 15026-1:2013, which has been technically revised.
The main changes compared to the previous edition are as follows:
— definitions of terms introduced in ISO/IEC 15026-3:2015 are added;
— definitions of terms whose definitions are modified in ISO/IEC 15026-3:2015 are updated.
A list of all parts in the ISO/IEC/IEEE 15026 series can be found on the ISO website.
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.
© ISO/IEC 2019 – All rights reserved
iv © IEEE 2019 – All rights reserved

Introduction
Software and systems assurance and closely related fields share concepts but have different vocabularies
and perspectives. This document provides a unifying set of underlying concepts and an unambiguous
use of terminology across these various fields. It provides a basis for elaboration, discussion and
recording agreement and rationale regarding concepts and the vocabulary used uniformly across ISO/
IEC/IEEE 15026 (all parts).
This document clarifies concepts needed for understanding software and systems assurance and,
in particular, those central to the use of ISO/IEC 15026-2, ISO/IEC 15026-3 and ISO/IEC 15026-4. It
supports shared concepts, issues and terminology applicable across a range of properties, application
domains and technologies.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC/IEEE 15026-1:2019(E)
Systems and software engineering — Systems and software
assurance —
Part 1:
Concepts and vocabulary
1 Scope
This document defines assurance-related terms and establishes an organized set of concepts and
relationships to form a basis for shared understanding across user communities for assurance. It
provides information to users of the other parts of ISO/IEC/IEEE 15026 including the combined use
of multiple parts. The essential concept introduced by ISO/IEC/IEEE 15026 (all parts) is the statement
of claims in an assurance case and the support of those claims through argumentation 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.
Assurance for a service being operated and managed on an ongoing basis is not covered in ISO/IEC/
IEEE 15026 (all parts).
A variety of potential users of ISO/IEC/IEEE 15026 (all parts) exists including 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. ISO/IEC/IEEE 15026 (all parts) uses concepts and terms consistent
with ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288 and generally consistent with the ISO/IEC 25000
series, but the potential users of ISO/IEC/IEEE 15026 (all parts) need to understand the differences
from concepts and terms to which they may be accustomed. This document attempts to clarify these
differences.
The primary purpose of this document is to aid users of the other parts of ISO/IEC/IEEE 15026 by
providing context, concepts and explanations for assurance, assurance cases and integrity levels. 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 of which a
number are referenced and included in the Bibliography.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
ISO, IEC and IEEE maintain terminological databases for use in standardization at the following
addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
— IEEE Standards Dictionary Online: available at http: //dictionary .ieee .org
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 1

3.1 Terms related to assurance and properties
3.1.1
assurance
grounds for justified confidence that a claim (3.1.4) has been or will be achieved
3.1.2
assurance case
reasoned, auditable artefact created that supports the contention that its top-level claim (3.1.4) (or set
of claims) is satisfied, including systematic argumentation and its underlying evidence and explicit
assumptions that support the claim(s)
Note 1 to entry: An assurance case contains the following and their relationships:
— one or more claims about properties;
— arguments that logically link the evidence and any assumptions to the claim(s);
— a body of evidence and possibly assumptions supporting these arguments for the claim(s); and
— justification of the choice of top-level claim and the method of reasoning.
3.1.3
attribute
inherent property 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.3), process (3.2.1), or system (3.2.4) (e.g., the price of
a product, the owner of a product).
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.2]
3.1.4
claim
true-false statement about the limitations on the values of an unambiguously defined property — called
the claim's property — 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.5)
Note 1 to entry: Uncertainties may also be associated with the duration of applicability and the stated conditions.
Note 2 to entry: A claim potentially contains the following:
— property of the system-of-interest;
— 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; and
— condition-related uncertainty.
Note 3 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.
© ISO/IEC 2019 – All rights reserved
2 © IEEE 2019 – All rights reserved

3.1.5
condition
measurable qualitative or quantitative attribute (3.1.3) that is stipulated for a requirement (3.2.5) and
that indicates a circumstance or event under which a requirement applies
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.6]
3.1.6
constraint
externally imposed limitation on the system (3.2.4), its design, or implementation or on the process
(3.2.1) 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.7
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.2 Terms related to product and process
3.2.1
process
set of interrelated or interacting activities that transforms inputs into outputs
Note 1 to entry: The definition for this term can also be found in ISO 9000 and ISO/IEC/IEEE 12207.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.30, modified — Note 1 to entry has been added.]
3.2.2
process view
description of how a specified purpose and set of outcomes may be achieved by employing the activities
and tasks of existing processes (3.2.1)
Note 1 to entry: The process view concept is introduced in ISO/IEC/IEEE 15288:2015, Annex E and ISO/IEC/
IEEE 12207:2017, Annex E.
3.2.3
product
result of a process (3.2.1)
Note 1 to entry: There are four agreed generic product categories: hardware (e.g., engine mechanical part);
software (e.g., computer program); services (e.g., transport); and processed materials (e.g., lubricant). Hardware
and processed materials are generally tangible products, while software or services are generally intangible.
Note 2 to entry: Results could be components, systems (3.2.4), software, services, rules, documents, or many
other items.
Note 3 to entry: The “result” could in some cases be many related individual results. However, claims (3.1.4)
usually relate to specified versions of a product.
Note 4 to entry: The definition for this term can also be found in ISO 9000 and ISO/IEC/IEEE 12207.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.32, modified—Notes 2 to 4 to entry have been added.]
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 3

3.2.4
system
combination of interacting elements organized to achieve one or more stated purposes
Note 1 to entry: A system is sometimes considered as a product (3.2.3) 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.
Note 4 to entry: The definition for this term can also be found in ISO/IEC/IEEE 12207.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.46, modified — Note 4 to entry has been added.]
3.2.5
requirement
statement which translates or expresses a need and its associated constraints (3.1.6) and conditions (3.1.5)
Note 1 to entry: Requirements exist at different levels in the system (3.2.4) 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.6
system element
member of a set of elements that constitutes a system (3.2.4)
EXAMPLE Hardware, software, data, humans, processes (3.2.1) (e.g., processes for providing service to
users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities or any
combination.
Note 1 to entry: A system element is a discrete part of a system that can be implemented to fulfill specified
requirements (3.2.5).
Note 2 to entry: The definition for this term can also be found in ISO/IEC/IEEE 12207.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.47, modified — Note 2 to entry has been added.]
3.3 Terms related to integrity level
3.3.1
integrity level
degree of confidence that the system-of-interest (3.3.12) meets the associated integrity level claim (3.3.4)
Note 1 to entry: While a definition of “integrity level” is given, existing definitions and the relevant communities
do not agree on a definition of “integrity” consistent with its use in “integrity level”. Hence, no separate definition
of “integrity” is included in this document. For the definition of “integrity” used in ISO/IEC JTC 1/SC 7, see ISO/
IEC 25010:2011, 4.1.6.2.
Note 2 to entry: An integrity level is different from the likelihood (3.3.6) 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.2) and hence cover safety,
security, economic and any other dimension of risk that is relevant to the system-of-interest.
© ISO/IEC 2019 – All rights reserved
4 © IEEE 2019 – All rights reserved

3.3.2
integrity level requirements
set of requirements (3.2.5) that, when met, will provide a level of confidence in the associated integrity
level claim (3.3.4) commensurate with the associated integrity level (3.3.1)
Note 1 to entry: An integrity level requirement is different from any requirement in ISO/IEC/IEEE 15288 or ISO/
IEC/IEEE 12207.
3.3.3
initial risk
estimated risk (3.4.2) before applying risk reduction measures (3.3.9)
3.3.4
integrity level claim
proposition representing a requirement (3.2.5) on a risk reduction measure (3.3.9) identified in the risk
treatment (3.3.11) process (3.2.1) of the system-of-interest (3.3.12)
Note 1 to entry: In general, it is described in terms of requirements to avoid, control or mitigate the consequences
(3.4.1) of dangerous conditions (3.4.11), so as to provide a tolerable risk (3.3.15) if it is met.
Note 2 to entry: The proposition that can be regarded as an integrity level claim in IEC 61508 is that an E/E/
PE safety-related system (3.2.4) satisfactorily performing the specified safety functions under all the stated
conditions.
3.3.5
level of risk
magnitude of a risk (3.4.2) or combination of risks, expressed in terms of the combination of consequences
(3.4.1) and their likelihood (3.3.6)
[SOURCE: ISO Guide 73:2009, 3.6.1.8]
3.3.6
likelihood
chance of something happening
[SOURCE: ISO Guide 73:2009, 3.6.1.1, modified — NOTEs 1 and 2 have been removed.]
3.3.7
residual risk
risk (3.4.2) remaining after risk treatment (3.3.11)
[SOURCE: ISO Guide 73:2009, 3.8.1.6, modified — NOTEs 1 and 2 have been removed.]
3.3.8
risk criteria
terms of reference against which the significance of a risk (3.4.2) is evaluated
[SOURCE: ISO Guide 73:2009, 3.3.1.3, modified — NOTEs 1 and 2 have been removed.]
3.3.9
risk reduction measure
measure to reduce or mitigate risk (3.4.2)
Note 1 to entry: A typical risk reduction measure is a safety-related system (3.2.4) in the IEC 61508 series.
3.3.10
risk source
element which alone or in combination has the intrinsic potential to give rise to risk (3.4.2)
Note 1 to entry: A hazard in ISO Guide 73 is an instance of a risk source.
Note 2 to entry: A fault (3.4.6), an error (3.4.5) or a failure (3.4.9) in the context of reliability can be a risk source.
The definitions of those terms can be found in IEC 61508-4.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 5

Note 3 to entry: A threat in the context of security and a threat agent (3.3.14) and an adverse action defined in
ISO/IEC 15408-1 can be a risk source.
[SOURCE: ISO Guide 73:2009, 3.5.1.2, modified — NOTE has been removed: Notes 1, 2 and 3 to entry
have been added.]
3.3.11
risk treatment
process (3.2.1) to eliminate risk (3.4.2) or reduce it to a tolerable level
[SOURCE: ISO Guide 73:2009, 3.8.1, modified — The words “modify risk” have been replaced with
“eliminate risk or reduce it to a tolerable level”; NOTEs 1, 2 and 3 have been removed.]
3.3.12
system-of-interest
system whose life cycle is under consideration
Note 1 to entry: The definition for this term can also be found in ISO/IEC/IEEE 15288.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.63, modified — The abbreviated term “SOI” has been removed;
Note 1 to entry has been added.]
3.3.13
target risk
risk (3.4.2) that is intended to be reached
[SOURCE: IEC 61508-4:2010, 3.1.10, modified — Restriction of the hazard has been removed.]
3.3.14
threat agent
entity that can adversely act on property-of-interest (3.4.12)
[SOURCE: ISO/IEC 15408-1:2008, 3.1.71, modified — The word “assets” has been replaced with
“property-of-interest”.]
3.3.15
tolerable risk
level of risk (3.3.5) 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, e.g., see ISO/IEC/IEEE 16085, and
ISO 14971. The general risk management standards ISO Guide 73 and ISO 31000 use both phrases without
explicit definitions.
[SOURCE: ISO/IEC Guide 51:2014, 3.7, modified — Note 1 to entry has been added.]
3.4 Terms related to conditions and consequences
3.4.1
consequence
outcome of an event affecting objectives
[SOURCE: ISO Guide 73:2009, 3.6.1.3, modified — NOTEs 1, 2 and 3 have been removed.]
3.4.2
risk
effect of uncertainty on objectives
Note 1 to entry: An effect is a deviation from the expected — positive and/or negative. In this document the focus
is on negative deviations leading to adverse consequences (3.4.3).
Note 2 to entry: Risk is often characterized by reference to potential events and consequences (3.4.1), or a
combination of these.
© ISO/IEC 2019 – All rights reserved
6 © IEEE 2019 – All rights reserved

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.3.6) 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 (3.5.1) -wide, project, product (3.2.3) and
process (3.2.1).
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 Guide 73:2009, 1.1, modified — NOTEs have been reordered; information specific to this
document has been added in Notes 1 and 3 to entry.]
3.4.3
adverse consequence
consequence (3.4.1) that results in a specified level of loss
Note 1 to entry: An adverse consequence results from the system-of-interest (3.3.12) being in a dangerous
condition (3.4.11) combined with the environment of the system (3.2.4) being in its worst case state.
Note 2 to entry: Harm in ISO 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.4
desirable consequence
positive consequence
consequence (3.4.1) associated with a benefit or gain or avoiding an adverse consequence (3.4.3)
3.4.5
error
discrepancy between a computed, observed or measured value or condition (3.1.5), 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.6
fault
defect in a system (3.2.4) or a representation of a system that if executed/activated can potentially
result in an error (3.4.5)
Note 1 to entry: Faults can occur in specifications when they are not correct.
3.4.7
attack
malicious action or interaction with the system (3.2.4) or its environment that has the potential to result in
a fault (3.4.6) or an error (3.4.5), and thereby possibly in a failure (3.4.9), or an adverse consequence (3.4.3)
3.4.8
violation
behaviour, act or event deviating from a system’s (3.2.4) desired property or claim (3.1.4) 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.
3.4.9
failure
termination of the ability of a system (3.2.4) to perform a required function or its inability to perform
within previously specified limits; an externally visible deviation from the system’s specification
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 7

3.4.10
systematic failure
failure (3.4.9) related in a deterministic way to a certain cause that can only be eliminated by
a modification of the design or of the manufacturing process (3.2.1), operational procedures,
documentation or other relevant factors
3.4.11
dangerous condition
state of a system (3.2.4) that, in combination with some states of the environment, will result in an
adverse consequence (3.4.3)
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 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.5) in the
reliability, integrity, confidentiality or dependability (3.1.7) contexts and other states of a system which can lead
to adverse consequences.
Note 2 to entry: Occurrences of failures (3.4.9) in the context of reliability or of a definition in IEC 61508-4 often
lead to dangerous conditions but not always do.
Note 3 to entry: A dangerous condition therefore has at least the following attributes (3.1.3):
a) the associated adverse consequences,
b) the trigger events that lead to the dangerous condition, and
c) the trigger events that lead to the adverse consequences from the dangerous condition.
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.1).
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.5 Terms related to organization
3.5.1
organization
group of people and facilities with an arrangement of responsibilities, authorities and relationships
EXAMPLE Company, corporation, firm, enterprise, institution, charity, sole trader, association, or parts or
combination thereof.
Note 1 to entry: An identified part of an organization (even as small as a single individual) or an identified group
of organizations can be regarded as an organization if it has responsibilities, authorities and relationships. A body
of persons organized for some specific purpose, such as a club, union, corporation, or society, is an organization.
Note 2 to entry: The definition for this term can also be found in ISO/IEC/IEEE 12207.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.27]
3.5.2
approval authority
person (or persons) and/or organization (3.5.1) (or organizations) responsible for approving activities,
artefacts and other aspects of the system (3.2.4) 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 different levels of approval and/or different areas of interest.
© ISO/IEC 2019 – All rights reserved
8 © IEEE 2019 – All rights reserved

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.3) developed by a single-party, the
independence of the approval authority can be a relevant issue to the acquirer.
3.5.3
design authority
person or organization (3.5.1) that is responsible for the design of the product (3.2.3)
3.5.4
integrity assurance authority
independent person or organization (3.5.1) responsible for certifying compliance with the integrity
level requirements (3.3.2)
4 Organization of this document
Clause 5 covers basic concepts such as assurance, stakeholders, systems and products, uncertainty
and consequence. Clause 6 covers some issues of which users of ISO/IEC 15026-2, ISO/IEC 15026-3 and
ISO/IEC 15026-4 need to be initially aware of. Clause 6, Clause 7 and Clause 8 cover terms, concepts
and topics particularly relevant to users of ISO/IEC 15026-2, ISO/IEC 15026-3 and ISO/IEC 15026-4,
respectively, although users of one part can also benefit from some of the information in the clauses for
other parts. A Bibliography is included at the end. References to numbered items in the Bibliography
are shown in brackets throughout.
5 Basic concepts
5.1 General
This clause covers the concepts and vocabulary fundamental to ISO/IEC/IEEE 15026 (all parts).
5.2 Assurance
ISO/IEC/IEEE 15026 (all parts) uses a specific definition for assurance as being grounds for justified
confidence. Generally, stakeholders need grounds for justifiable 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 need for strong grounds for confidence.
The appropriate valid arguments and evidence to establish a rational basis for justified confidence in
the relevant claims about the system’s properties need to be made. These properties may include such
aspects as future costs, behaviour and consequences. Throughout the life cycle, adequate grounds need
to exist for justifying 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
achieving and/or showing a claim. 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 may relate to:
a) would the system or software as specified meet real-world needs and expectations,
b) would or does the as-built and operated system meet the specifications, or
c) both a) and b).
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 9

Specifications may be representations of static and/or dynamic aspects of the system. Specifications
often include descriptions of capability, functionality, behaviour, structure, service and responsibility
including time-related and resource-related aspects as well as limitations on frequency or seriousness
of deviations by the product and related uncertainties.
Specifications may be prescriptions and/or constraints (e.g., for and on product behaviours) and may as
well include measures of merit and directions regarding trade-offs. Generally, specifications place some
limitations on the environment and its conditions (e.g., temperature) and possibly the conditions of the
product (e.g., age or amount of wear).
5.3 Stakeholders
Through their life cycle, systems and software have multiple stakeholders who affect or are affected
by the system and the system life cycle processes. Stakeholders might benefit from, incur losses from,
impose constraints on, or otherwise have a “stake” in the system, and therefore are those that provide
the requirements for the system. Stakeholders can include non-users whose performance, results
or other requirements might be affected, e.g., entities whose software is executing on the same or
networked computers.
A different but important kind of stakeholder is an attacker, who certainly imposes constraints or has
interests involved with the system. This document includes the attacker as a stakeholder; however, some
in the security community and elsewhere exclude attackers from their use of the term “stakeholders.”
The relevant stakeholders whose requirements are of concern include not only the system’s owners and
users, but also developers and operators who need to identify requirements for the development and
operation of the system. Depending on conditions and consequences, the various stakeholders require
grounds for justified confidence in properties of the system for which they identified requirements.
5.4 System and product
To be consistent with ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15026 (all parts)
uses the term “system” throughout. Users of this document who are more familiar with using the term
“product” should note that “system” includes products and services that are the results of processes as
well as software and system or software elements or components. While primarily motivated by concern
for systems produced (at least in part) by human-controlled or artificial processes, this document can
be used in reducing uncertainty about a system’s dependence on natural phenomena as well.
5.5 Property
5.5.1 General
ISO/IEC/IEEE 15026 (all parts) relates assurance to requirements of a property of a system or software
product. Properties are entities that can be predicated of things or, in other words, attributed to
[176]
them . Therefore, a property might be a condition, a characteristic, an attribute, a quality, a trait,
a measurement or a consequence. A property might be invariant or dependent on time, situation or
history. In ISO/IEC/IEEE 15026 (all parts), a property is expected to be relevant directly or indirectly to
a system or systems and thus have related requirements.
Properties may have requirements for what they were in the past, what they are presently or what
they will be in the future. Generally, the last is the most important in ISO/IEC/IEEE 15026 (all parts).
As this knowledge involves predicting the future, it is often the most difficult and uncertain to attain;
therefore, a system’s future behaviour and consequences (see 5.8) often become principal issues in its
assurance.
Many of the properties with requirements are qualities of the system. Several standards and reports
provide lists and definitions of qualities that could be the subject of assurance including ISO/IEC 25010
and the related series, ISO/IEC 2382, ISO 9241 and ISO/TS 25238.
© ISO/IEC 2019 – All rights reserved
10 © IEEE 2019 – All rights reserved

This use of the term “property” derives from, is consistent with and subsumes the broad use of the term
“property” in ISO/IEC 25010 where it is used spanning properties that are inherent or not, internal,
external, and in use or context.
Producers and other stakeholders may prioritize properties such as efficiency and reliability and
perform trade-off studies between them and their related requirements. A number of techniques have
been created for addressing these trades, such as those in References [87], [53], [124], [159] and [102].
The specifying of a top-level claim for a property is sometimes the result of analyses including trade-off
studies.
5.5.2 Properties as behaviours
Often the property is specified as behaviour. During performed operations, behaviour-related
properties might be formally specified as a combination of:
— restriction on allowed system states (sometimes call
...