ISO/IEC TR 7052:2023

TECHNICAL ISO/IEC TR
REPORT 7052
First edition
2023-09
Software engineering — Controlling
frequently occurring risks during
development and maintenance of
custom software
Ingéniérie du logiciel — Contrôle des risques fréquents au cours du
développement et de la maintenance d'un logiciel sur mesure
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
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’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms .11
5 Explanatory note on terms .11
5.1 The term risk . 11
5.2 The term control . 11
6 Risks .12
6.1 General .12
6.2 Product-related risks . 13
6.2.1 General .13
6.2.2 Risk 01: The quality of the software is reduced because of modifications to
it . 13
6.2.3 Risk 02: The quality of the software is reduced because of modifications to
the environment in which it runs . 13
6.3 Project-related risks . 14
6.3.1 General . 14
6.3.2 Risk 03: Planned functionality is not completed on time because of
underestimation of the amount of work involved . 14
6.3.3 Risk 04: The product is not delivered on time and within budget because
the scope is changed . 14
6.3.4 Risk 05: The software does not meet the requirements laid down because
the team does not have the required expertise .15
6.3.5 Risk 06: The product does not offer the right functionality because of
inadequate management of the work . 15
6.3.6 Risk 07: The product lacks the right non-functional properties because
functional requirements were given too much priority . 16
6.3.7 Risk 08: Misunderstandings occur because the communication between
stakeholders is poor . 16
6.3.8 Risk 09: Custom software does not (demonstrably) meet obligations
because development, use and maintenance were not sufficiently auditable . 17
6.3.9 Risk 10: The product is not delivered on time because a great deal of time
was needed to set up for software development . 17
7 Controls . .18
7.1 General . 18
7.2 Project-related controls . 18
7.2.1 General . 18
7.2.2 Project preparation . 19
7.2.3 Project execution .23
7.2.4 Completion of development and/or maintenance . . 27
7.3 Organization-related controls .28
7.3.1 Control 16: Supporting teams with specialist knowledge and tools .28
7.3.2 Control 17: Continuous risk management .29
Annex A (informative) Overview of risks and controls .31
Annex B (informative) Assessment tool .33
Bibliography .35
iii
© ISO/IEC 2023 – All rights reserved

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).
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.
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.
iv
© ISO/IEC 2023 – All rights reserved

Introduction
Information and communication technology (ICT) projects run many risks. ICT projects often have to
contend with delay, budget overruns, and an end result of low quality.
ICT projects in which custom software is developed and/or maintained often run extra risks, on top
[31]
of the risks that are part and parcel of ICT projects in general . This seems to be caused by the sheer
size and complexity of such custom software projects, and by a failure to mitigate the risks inherent to
software development in general, despite the fact that they are well known, and that there are suitable
controls for their management.
This document describes controls for some of the risks inherent in custom software development.
The purpose of this document is that during the development of custom software stakeholders can
avail themselves of a collection of suitable controls. The controls included are common of themselves,
making this collection of controls a logical starting point for assuring the quality of custom software
development. Controls were selected for inclusion based on the experience and opinion of the subject
matter experts contributing to this document.
Two target groups are important when mitigating risks during the development of custom software:
a) the software development acquirers and suppliers;
b) the end users and maintainers of the software developed.
This document details risks and controls specific to custom software development. Risk management
in the context of software development is covered in ISO/IEC/IEEE 12207 and its elaboration standard
ISO/IEC/IEEE 16085. Generic risk management is covered by ISO 31000 and its related standards.
This document is based on NPR 5326 developed by Royal Netherlands Standardization Institute
Foundation (NEN, https://www.nen.nl/).
v
© ISO/IEC 2023 – All rights reserved

TECHNICAL REPORT ISO/IEC TR 7052:2023(E)
Software engineering — Controlling frequently occurring
risks during development and maintenance of custom
software
1 Scope
This document:
— describes frequently occurring risks during development and maintenance of custom software;
— describes possible controls for frequently occurring risks;
— describes the related:
— activities, facilities and roles typically used for these controls;
— properties of products and processes;
— standards, measurements, testing and assessment of the properties of products and processes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC 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/
3.1
acceptance test-driven development
ATDD
development method where team members with various backgrounds [developers (3.18), testers and
business analysts] jointly write the acceptance tests prior to development of the relevant functionality
Note 1 to entry: Although the name of the method, acceptance test-driven development, suggests that ATDD
is a specialization of test-driven development (3.46) (TDD), this is not the case. Rather, TDD focuses on driving
development by writing unit tests (3.48) first and ATDD focuses on driving development by writing acceptance
tests first.
[SOURCE: NEN NPR 5326:2019, 3.1, modified —Added note 1 to entry.]
3.2
acquirer
stakeholder that acquires or procures a product or service from a supplier (3.44)
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or internal/
organizational sponsor.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.1]
© ISO/IEC 2023 – All rights reserved

3.3
agile development
development approach based on iterative development, frequent inspection and adaptation, and
incremental deliveries in which requirements and solutions evolve through collaboration in cross-
functional teams and through continuous stakeholder feedback
Note 1 to entry: Any use of the word “agile” in this document refers to methodology.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1, modified — In note 1 to entry, removed the reference to
ISO/IEC/IEEE 26515:2018, Annex A.]
3.4
backlog
collection of agile features or stories of both functional and non-functional requirements that are
typically sorted in an order based on value priority
Note 1 to entry: This can be used as a list of product requirements and deliverables (3.13) not part of current
work, to be prioritized and completed.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.4, modified — Removed note 1 to entry.]
3.5
behaviour-driven development
BDD
development method where team members with various backgrounds [developers (3.18), testers and
business analysts] jointly describe the behaviour of the intended functionality prior to development of
the relevant functionality
[SOURCE: NEN NPR 5326:2019, 3.5]
3.6
burndown
indicator of the work completed and estimate of remaining work to be completed or remaining effort
needed to complete a product development iteration cycleNote 1 to entry: Work is measured as all work
done to deliver story points, stories, features, functions, function points (3.25), user stories (3.50), use
cases (3.49), or requirements during a product development iteration.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.437, modified — Restructured into definition and note 1 to
entry.]
3.7
burndown chart
graph that represents the work remaining to do on a project
Note 1 to entry: See Figure 1 for an example of a burndown chart.
© ISO/IEC 2023 – All rights reserved

Key
1 solid line, representing the actual work-remaining
2 stippled line, representing the ideal burndown of the work
Figure 1 — Example of a burndown chart with time on the horizontal axis and work-remaining
on the vertical axis
Note 2 to entry: This can be used as a chart to show the amount of the work done versus the amount of the work
still to do.
Note 3 to entry: This can be presented per sprint (3.42), as well as per release or iteration.
Note 4 to entry: For example, user story points (3.51) or function points (3.25) can be used to measure the amount.
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.6, modified — Added the example figure and notes to entry.]
3.8
business impact analysis
process of analysing the impact over time of a disruption on the organization
Note 1 to entry: The outcome is a statement and justification of business continuity requirements.
[SOURCE: ISO 22300:2021, 3.1.24]
3.9
code review
activity where one or more developers (3.18) establish the quality (3.35) of (part of) the source code
(3.41) by going through it
Note 1 to entry: There are a variety of ways to conduct code reviews which range from formal to very informal
and from discrete to continuous.
[SOURCE: NEN NPR 5326:2019, 3.10, modified — Modified definition and added note 1 to entry.]
3.10
configuration management database
CMDB
database that is used by an organization to store information about the hardware and software in use
[SOURCE: NEN NPR 5326:2019 3.11]
© ISO/IEC 2023 – All rights reserved

3.11
consequence
outcome of an event (3.23) affecting objectives (3.30)
Note 1 to entry: An event can lead to a range of consequences.
Note 2 to entry: A consequence can be certain or uncertain and can have positive or negative effects on objectives.
Note 3 to entry: Consequences can be expressed qualitatively or quantitatively.
Note 4 to entry: Initial consequences can escalate through knock-on effects.
[SOURCE: ISO Guide 73:2009, 3.6.1.3]
3.12
control
measure that is modifying risk (3.37)
Note 1 to entry: Controls include any process, policy, device, practice, or other actions which modify risk.
Note 2 to entry: Controls cannot always exert the intended or assumed modifying effect.
[SOURCE: ISO Guide 73:2009, 3.8.1.1, modified — In note 2 to entry, changed “may not” to “cannot”.]
3.13
custom software
software product developed for a specific application from a user requirements specification
[SOURCE: ISO/IEC 25000:2014, 4.3]
3.14
data protection impact assessment
DPIA
tool described in the General Data Protection Regulation (3.27) (GDPR) to assess in advance the privacy
risks of data processing and then to be able to implement controls (3.12) to reduce the risks (3.37)
Note 1 to entry: See https:// gdpr .eu/ article -35 -impact -assessment/ .
[SOURCE: NEN NPR 5326:2019 3.12, modified — Changed “take measures” to “implement controls”.
Added note 1 to entry with link to the GDPR Article 35.]
3.15
deliverable
any unique and verifiable product, result, or capability to perform a service that must be produced to
complete a process, phase, or project
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1098, definition 1]
3.16
Delphi method
information-gathering technique used as a way to reach consensus of experts on a subject
Note 1 to entry: The Delphi method is applied as consensus tool for determining weights of indicators/sub-
indicators in this document.
Note 2 to entry: A facilitator uses a questionnaire to solicit ideas about the important project points related to the
subject. The responses are summarized and are then recirculated to the experts for further comment. Consensus
can be reached in a few rounds of this process.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1102, modified — Restructured into definition and notes to
entry.]
© ISO/IEC 2023 – All rights reserved

3.17
design thinking
methodology for solving (very complex) problems where these are defined from the human needs
Note 1 to entry: In design thinking solutions are determined with brainstorming sessions, where prototypes
(3.34) are produced to test the intended solution in practice.
[SOURCE: NEN NPR 5326:2019, 3.15]
3.18
developer
individual or organization that performs development activities (including requirements analysis,
design, testing through acceptance) during the system or software life-cycle process
Note 1 to entry: Activities of the developer of custom software (3.13) include setup and analysis of functional and
non-functional system and software requirements, design, programming and testing.
Note 2 to entry: Designers, programmers and testers are therefore all developers.
[SOURCE: ISO/IEC 25000:2014, 4.6. modified — Added notes to entry.]
3.19
development pipeline
build pipeline
set of tools aimed at the managed and controlled build of a package with which an application can be
taken into use
Note 1 to entry: As part of this various tests are carried out to determine and assess quality (3.35).
[SOURCE: NEN NPR 5326:2019, 3.30]
3.20
development team
team that develops and/or maintains software
Note 1 to entry: The acquirer (3.2), product owner (3.33) and future maintainer can form part of the development
team.
Note 2 to entry: Development teams can be broken down by function (e.g. a team of designers, a team of
programmers, a team of testers) or be multidisciplinary (each team has e.g. design, programming and test
expertise).
[SOURCE: NEN NPR 5326:2019, 3.31]
3.21
DevOps
set of principles and practices which enable better communication and collaboration between relevant
stakeholders for the purpose of specifying, developing, and operating software and systems products
and services, and continuous improvements in all aspects of the life cycle
[SOURCE: IEEE 2675-2021 3.1]
3.22
distributed denial of service attack
DDoS attack
unauthorized access to a system resource or the delaying of system operations and functions in the way
of compromising multiple systems to flood the bandwidth or resources of the targeted system, with
resultant loss of availability to authorized users
[SOURCE: ISO/IEC 27039:2015, 3.7]
© ISO/IEC 2023 – All rights reserved

3.23
event
occurrence or change of a particular set of circumstances
Note 1 to entry: An event can be one or more occurrences and can have several causes.
Note 2 to entry: An event can consist of something not happening.
Note 3 to entry: An event can sometimes be referred to as an ‘incident’ or ‘accident’.
Note 4 to entry: An event without consequences (3.11) can also be referred to as a ‘near miss’, ‘accident’, ‘near hit’
or ‘close call’.
[SOURCE: ISO Guide 73:2009, 3.5.1.3]
3.24
extreme programming
XP
form of agile software development where procedures for iterative planning and working are combined
with technical procedures, such as test-driven design and pair programming
[SOURCE: NEN NPR 5326:2019, 3.20]
3.25
function point
FP
unit of measure for functional size
[SOURCE: ISO/IEC 20926:2009, 3.35, modified — removed “as defined within this International
Standard”.]
3.26
function point analysis
FPA
method for measuring functional size
[SOURCE: ISO/IEC 20926:2009, 3.36, modified — removed “as defined within this International
Standard”.]
3.27
General Data Protection Regulation
GDPR
European Regulation that standardizes the rules for processing personal data by private businesses
and government bodies in the whole European Union
Note 1 to entry: See https:// gdpr .eu.
[SOURCE: NEN NPR 5326:2019, 3.3]
3.28
integration testing
testing in which software components, hardware components, or both are combined and tested to
evaluate the interaction between them
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2034, modified — Removed note 1 to entry.]
© ISO/IEC 2023 – All rights reserved

3.29
minimum viable product
MVP
version of a work product with just enough features and requirements to satisfy early customers and/
or provide feedback for future development
[SOURCE: IEEE 2675-2021, 3.1]
3.30
objective
predetermined result to be achieved
Note 1 to entry: To achieve an objective several tools and activities are generally needed, one of which can be
custom software (3.13).
[SOURCE: NEN NPR 5326:2019, 3.18]
3.31
performance test
test type conducted to evaluate the degree to which a test item accomplishes its designated functions
within given constraints of time and other resources
Note 1 to entry: A distinction is often made between load, stress and endurance tests. Load tests simulate a
normal load on the system. Stress tests allow the load to increase to determine the maximum load at which the
system still functions. Endurance tests load the system for a longer period in order to discover memory leaks or
other problems which only manifest themselves after some time.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.58, modified — Changed the term from "performance testing"
to "performance test"; changed "type of testing" to "test type"; added note 1 to entry.]
3.32
product breakdown structure
PBS
decomposition of the product into its components
Note 1 to entry: The PBS begins with the complete product at the top of the hierarchy and below this the main
components, which can also each be broken down again into components, etc.
[SOURCE: ISO 21511:2018, 3.7, modified — Added the abbreviated term and note 1 to entry.]
3.33
product owner
stakeholder responsible for the capabilities, acceptance and use of a product
Note 1 to entry: The product owner shares the product vision, required features and their priorities, and
acceptance criteria.
[SOURCE: ISO/IEC TR 24587:2021, 3.12]
3.34
prototype
model or preliminary implementation suitable for evaluation of system design, performance, and
production potential, or for better understanding or determination of the requirements
[SOURCE: ISO/IEC 2382:2015, 2122670, modified — Removed notes to entry.]
3.35
quality
ability of a product, service, system, component, or process to meet customer or user needs,
expectations, or requirements
Note 1 to entry: For the quality of software and IT systems, ISO/IEC 25010 offers a breakdown into aspects, such
as:
© ISO/IEC 2023 – All rights reserved

— reliability;
— security;
— usability;
— functional suitability;
— maintainability;
— portability;
— performance efficiency;
— compatibility.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3259, definition 2, modified — Added note 1 to entry.]
3.36
regression test
test type used following modifications to a test item or to its operational environment, to identify
whether regression failures occur
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.64, modified — Changed to term from "regression testing" to
"regression test"; changed "testing performed" to "test type used"; changed "failures in unmodified
parts of the test item" to " regression failures": removed notes to entry.]
3.37
risk
effect of uncertainty on objectives (3.30)
[SOURCE: ISO Guide 73:2009, 1.1, modified — Notes to entry removed]
3.38
risk treatment
process to modify a risk (3.37)
Note 1 to entry: Risk treatment can involve:
— avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
— taking or increasing risk in order to pursue an opportunity;
— removing the risk source;
— changing the likelihood;
— changing the consequences (3.11);
— sharing the risk with another party or parties (including contracts and risk financing and;
— retaining the risk based on an informed decision.
Note 2 to entry: Risk treatment that deal with negative consequences is sometimes referred to as ‘risk mitigation’,
‘risk elimination’, ‘risk prevention’ or ‘risk reduction’.
Note 3 to entry: Risk treatment can create new risks or modify existing risks.
[SOURCE: ISO Guide 73:2009, 3.8.1]
3.39
Scrum
iterative project management framework used in agile development (3.3), in which a team agrees on
development items from a requirements backlog (3.4) and produces them within a short duration of a
few weeks
© ISO/IEC 2023 – All rights reserved

3.40
security test
test type conducted to evaluate the degree to which a test item, and associated data and information, are
protected so that unauthorized persons or systems cannot use, read, or modify them, and authorized
persons or systems are not denied access to them
Note 1 to entry: Depending on the amount of information on the system to be tested that the security tester
has when carrying out the test, the terms black box (minimum information), grey box (the same knowledge and
access as an ordinary user) or white box security tests [access to the whole system, documentation and source
code (3.41)] are used.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.74, modified — Changed to term from "security testing" to
"security test"; added note 1 to entry.]
3.41
source code
computer instructions and data definitions expressed in a form suitable for input to an assembler,
compiler, or other translator
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3882, modified — Removed note 1 to entry.]
3.42
sprint
time box of one month or less during which a ‘done’, usable and potentially releasable product increment
is created
[SOURCE: NEN NPR 5326:2019, 3.44]
3.43
story mapping
making of a two-dimensional representation of (part of the) backlog (3.4) that is a visual aid for the user
to cut up, group and arrange stories logically in the backlog, which gives an overview of the relations
between all the user stories (3.50)
[SOURCE: NEN NPR 5326:2019, 3.45, modified — Changed the term from "story map" to "story
mapping".]
3.44
supplier
organization or an individual that enters into an agreement with the acquirer (3.2) for the supply of a
product or service
Note 1 to entry: Other terms commonly used for supplier are contractor, producer, seller, or vendor.
Note 2 to entry: The acquirer and the supplier sometimes are part of the same organization.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.60]
3.45
technical debt
deferred cost of work not performed at an earlier point in the product life cycle
Note 1 to entry: Suppliers (3.44) are often not able to explain properly to acquirers (3.2) why combatting and
avoiding technical debt is an important point to consider in the development of custom software (3.13), which can
make it difficult to avoid and deal with technical debt.
EXAMPLE:
— copying existing functionality to add a new function quickly without the resolving the duplication of source
code (3.41) that has arisen here;
— not including certain test cases in an automated regression test (3.36);
© ISO/IEC 2023 – All rights reserved

— not upgrading libraries or frameworks used to a more recent version;
— not setting up and performing integration testing with systems to be linked;
— not updating documentation;
— not making domain concepts used in the source code explicit (e.g. passing on ‘strings’ with street and post
code instead of creating a class for the concept ’address’).
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4181, modified — Added note 1 to entry and EXAMPLE.]
3.46
test-driven development
TDD
development method where the developers (3.18) write unit tests (3.48) prior to implementing the
relevant functionality
[SOURCE: NEN NPR 5326:2019, 3.47]
3.47
T-shirt sizing
method of making relative estimates by comparing user stories (3.50) and dividing these into the
categories extra-small, small, medium, large and extra large
Note 1 to entry: T-shirt sizing clarifies the interrelationships without time being wasted on false precision.
[SOURCE: NEN NPR 5326:2019, 3.48]
3.48
unit test
testing of individual routines and modules by the developer (3.18) or an independent tester
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4429 definition 1]
3.49
use case
description of behavioural requirements of a system and its interaction with a user
Note 1 to entry: A use case describes the users' goal and the requirements including the sequence of interactions
between users and the system.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.15]
3.50
user story
short description of what a user intends to achieve with part of the system
Note 1 to entry: A user story normally consists of a few sentences of ordinary spoken language of the acquirer
(3.2)/user which states what the user does or will be able to do to achieve a certain objective (3.30). In addition, a
user story describes what acceptance criteria are used to consider the functionality produced as complete.
Note 2 to entry: A commonly used format for user stories is: ‘As I can so that ’. For
example: ‘As an employee I can specify my expenses so that I have these reimbursed by my employer’.
3.51
user story point
relative measure for the scope of user stories (3.50), often used in agile development (3.3) methods
[SOURCE: NEN NPR 5326:2019, 3.52]
© ISO/IEC 2023 – All rights reserved

4 Abbreviated terms
ICT information and communication technologies
NEN Royal Netherlands Standardization Institute Foundation
SEI Software Engineering Institute
5 Explanatory note on terms
5.1 The term risk
Risk is the effect of uncertainty on achieving objectives. An effect is a deviation from the expectation –
positive and/or negative. A risk is often characterised by reference to possible events and consequences,
or a combination of these.
In the context of this document the term risk is interpreted as follows:
Uncertainty is caused by the chance of events occurring. There is only a risk if there is a chance of
events occurring that affect achieving objectives. If the chance of such events occurring is zero, there
is no risk. For example, for software containing no data that can be traced to persons, there is also no
chance of such data being stolen. If the chance of the relevant event occurring is one (i.e. 100 %), there is
also no risk. The event does occur with certainty.
An example of an event with an effect on achieving an objective is 'the systems to be linked are not
modified on time'. The chance of this event can be determined in various ways. One way is extrapolation
of historical data. Say that of the 30 projects that an organization has carried out that involve linking
systems to be modified, 13 were found not to have been modified on time. A (naive) probability
calculation then gives a chance of 13/30 · 100 % = 43 % that a project will have to deal with systems to
be linked that have not been modified on time. Of course, a risk assessment that considers more factors,
such as the number of systems to be linked, is more accurate.
In addition to the chance of an event occurring, it is at least as important to know what the effect is on
achieving objectives. An event that has no effect on the achievement of an objective does not form a risk.
If the cabinet falls, but this has no effect on realising the project objective because it is not a government
project, the event does not form a risk. An example of an event that does have an effect on achieving
objectives is unauthorized reading of data from the system developed. Such an event can have several
effects: the privacy of users is infringed, but also the reputation of the relevant organizations can be
damaged, and penalties imposed.
The effects relate to different objectives; in this case safeguarding the privacy of users and having a
reliable reputation.
Often there is only a risk if an event occurs which is certain to have a negative consequence on achieving
an objective. In the case of an event with a positive effect this is generally called an opportunity. In
complex (joint ventures of) organizations an apparently positive effect is also regarded as a risk.
Examples here are delivering functionality too early, so the organization that has to use this product is
not ready for it.
5.2 The term control
A control is a measure by which a risk is modified.
In the context of this document the term control is interpreted as follows: A control modifies the chance
of a risk occurring or changes the effect of a risk occurring, or both.
An example of a control for the event ‘a distributed denial of service (DDoS) attack occurs on the system’
is placing a hardware appliance in the IT infrastructure that filters network traffic and so reduces the
effect of the attack.
© ISO/IEC 2023 – All rights reserved

An example of a control that would reduce the chance of a DDoS attack is disallowing direct access to
the system via the Internet, and only allow access via an intranet or virtual private network (VPN).
Note that a control can also consist of the omission of acts. For example, take the risk that the efficiency
of a development team is negatively affected because the acquirer often interrupts the work of the
development team with new wishes to be dealt with or faults to be repaired immediately. This risk can
be reduced by agreeing that the development team divides the time into time boxes (in some software
development approaches referred to as sprints) and also agreeing that the acquirer cannot alter the list
of tasks on which the team is working during the current time box.
Controls can change risks in various ways. This is also called risk treatment. Examples of risk treatment
in the domain of custom software are as follows.
— Avoidance: the risk is avoided by not carrying out the activity that gives rise to the risk. For example,
by a system not downloading data via an interface from another system but storing all the data in its
own database, the risk is avoided that the other system cannot be accessed.
— Removal: the risk cannot occur because the control removes a risk source. For example, by not
building a function for which clear acceptance criteria have been formulated, the risk is removed
that the function does not meet the (implicit) requirements and wishes of the acquirer.
— Changing the likelihood: the control affects the likelihood of the risk occurring. For example, by
developing and running automated regression tests, the likelihood of not detecting faults in the
software in time becomes smaller.
— Changing consequences: the control affects the consequences of the risk occurring. For example, by
issuing a new version of the software for part of the users instead of for all the users at the same
time, the consequences of any faults in the software are limited to that part of the users.
— Sharing: the control ensures that the risk is shared with one or more other parties. For example,
developing software together with other organizations in a joint venture reduces the risk for each
of the participating organizations.
— Acceptance: the control consists of the justified maintenance of the risk (acceptance). The risk of
performance problems can for example be accepted if the number of intended users and the amount
of data to be processed is small.
— Transfer: the control consists of the transfer of the risk to another party. The risk of the development
environment not being available can for example (partly) be transferred to another party by
purchasing the development environment as a service from the relevant party.
6 Risks
6.1 General
This clause describes commonly occurring risks during the development and maintenance of custom
software. The risks described in this document are based on:
— the risk taxonomy from taxonomy-based risk identification [CMU/SEI-93-TR-06];
— the contribution of experiences with the development and maintenance of custom software of the
experts within the NEN standards committee;
— input from the field in the form of review comments during the drafting of NEN NPR 5326.
Annex A cross-references the risks and controls described in this document. Annex B provides one
method of performing a risk inventory or risk assessment.
© ISO/IEC 2023 – All rights reserved

6.2 Product-related risks
6.2.1 General
Product-related risks arise from work that is necessary to develop and/or maintain the custom
software.
6.2.2 Risk 01: The quality of the software is reduced because of modifications to it
Making changes to software involves the risk of the introduction of new faults or a re-occurrence of
previously repaired faults. Faults can occur due to incorrect assumptions or omissions in updating the
software, as well as because a more recent version of a software library is used.
Faults can emerge in the form of reductions in quality immediately which can be observed by users,
such as functions that do not work, lower performance or poorer usability, as well as in the form of
reductions in quality not immediately observed by users, such as reduced security or maintainability.
See ISO/IEC 25010 for a summary of various software quality aspects.
This type of regression often leads to dissatisfied acquirers and users, and many other types of damage
(injury, financial damage, reputation damage, etc.) but regression can also have a potential secondary
effect: it can lead to parties involved in the development and/or maintenance of the software becoming
reluctant to release software and take new versions into use. This makes it more difficult to implement
a number of controls that this document recommends for other risks. The importance of mitigating the
risks of regression is therefore greater than it would appear.
This risk can be reduced by applying the following controls:
— Control 09: Setting up automated development pipeline.
— Control 10: Constantly meeting the requirements with regression tests.
— Control 13: Using a quality-driven development method.
— Control 15: Proper handover.
6.2.3 Risk 02: The quality of the software is reduced because of modifications to the
environment in which it runs
Even without software being changed its quality can be reduced or it can stop working properly.
Without the source code of the software being altered, faults can occur, or faults can come to light. This
phenomenon is also called software decay and can often be explained by changes to the environment in
which the software is run.
Examples of changes in the environment that affect software quality are:
— newly discovered security vulnerabilities in libraries used that make the software more insecure;
— interfaces of other systems that change so that the software can no longer download data from
these systems;
— a new version of an operating system;
— more recent versions of browsers on the computers of end users;
— change in use of the software which brings to light faults that were not previously visible;
— network settings that change.
Most contr
...