How will blockchain impact

an information risk
management approach?

54 How will blockchain impact an information risk management approach?

Steven van der Weerd MSc
is a senior IT auditor at KPMG
Business Assurance.
[email protected]

Blockchain is considered an emerging technology that

has the potential to significantly transform the way we
transact. The establishment of new asset classes and
transactional models substitute conventional payment
and settlement platforms. The major advantage that
blockchain offers is transparency and elimination of
custodial necessity. However, organizations
implementing blockchain in their IT environment are also
faced with a new set of risks arising from this distributed
ledger technology. Before organizations can even
consider implementing blockchain, they should
understand its implications on their information risk
management strategy and how this translates to their
business. In this article we will take a closer look at
blockchain and how it differs from the more
‘conventional’ information systems. Based on the
uniqueness of blockchain technology, this article will
introduce some of the key risks arising from the
implementation of this technology in existing IT
environments. In addition, the article will describe how
these risks affect information risk management.
Facebook’s Libra platform will be used to apply our
insights to a real-life scenario. Lastly, the author will
conclude with a brief approach on auditing blockchain
systems and what IT auditors might take into
consideration when faced with this technology.
 INTRODUCTION how these risks affect information risk management.
This article will reflect on Facebook’s Libra platform to
Blockchain is considered a breakthrough in the field of apply our insights to a real-life scenario. Lastly, you will
distributed computing and has the potential to com- find a high-level approach for auditing blockchain sys-
pletely disrupt existing transactional models and busi- tems and what IT auditors might take into consideration
ness processes. As shown in a global survey conducted by when faced with this technology.
[Delo19] in 2019 (that polled over 1000 senior executives),
the technology is increasingly being researched by both
public as private organizations. One of the key results of UNDERSTANDING BLOCKCHAIN
the survey shows that “fifty-three percent of respondents
say that blockchain technology has become a critical Blockchain is considered a subset of distributed systems.
priority for their organisations in 2019” ([Delo19], p. 3). In general, a distributed system can be defined as a group
These developments are substantiated by Laszlo Peter, of independent computing elements working together
Head of KPMG Blockchain Services in the Asia Pacific: to achieve a common objective ([Stee16]). Now, distrib-
“Blockchain is certainly here to stay. While funding may uted systems are all around us: from airplanes to mobile
have slowed in 2019, it simply shows the growing matu- phones, anything can be considered a distributed system
rity of the market. It is a sign that investors are moving to a certain degree. Most of these distributed systems are
away from the ‘fear of missing out’ mentality (…) and are ‘closed’, where only authorized computing elements (i.e.
making more mature investment decisions and focusing agents) are able to access and operate within these sys-
on more meaningful initiatives” ([KPMG19], p. 16). tems. These agents trust each other, and communication
is considered safe. This makes sense, as we wouldn’t want
Given its newness, blockchain can still be considered an unknown agents to be able to access airplanes or our
innovative type of technology. But there is something mobile phones and perform harmful activities.
peculiar about innovative technologies and its appli-
cation by organizations: innovation can be considered Another example is the internet. In contrast to the two
a journey into the unknown. Innovation is exploring examples mentioned, the internet is a distributed sys-
how new technologies can be applied to business and IT tem where it is possible for unknown agents that do not
processes, this brings uncertainty: after all, if you venture trust each other, to operate in and perform activities that
into the unknown, you are not particularly certain about might be considered harmful to other agents (such as
what lies ahead; there are risks (downside and upside) as yourself) or even the overall system. If we want to per-
well as opportunities. form certain activities on the internet – such as sending
money to a party that you do not necessarily trust – we
Given the profound impact that blockchain might have rely on intermediaries such as financial institutions
on organizations and the way they transact with(in) each (banks) to ensure that the amount is actually debited
other, a thorough information risk management strategy to the bank account of the intended party and credited
should be designed. The risk management approach from the sending party. The banks function as a trusted
should be able to identify and address the risks arising third party that ensure that both parties involved in the
from blockchain and how blockchain-powered processes transaction are not able to fraud each other.
might impact the control environments surrounding
these processes. Designing a risk management approach How does this relate to blockchain and why exactly is
for blockchain will not only enable organizations to this technology considered a breakthrough in the field
remain in control; it will also help organizations design of distributed computing ([Kasi18])? On a general level,
and implement blockchain securely and appropriately in blockchain is simply one of the ways for multiple parties
their business and apply the effective operation of gov- to reach an agreement (i.e. consensus) on the state of
ernance structures for blockchains that are transacted the system (e.g. a ledger or a digital transaction being
by multiple organizations. However, before information recorded on that ledger) on a given time without hav-
risk management professionals can start to think of ing to rely on a trusted third party or central authority
designing a blockchain risk management approach, it is (such as the bank in the example above). Systems that
essential that risk professionals profoundly understand allow for this multi-party consensus are considered to be
blockchain, and how it differs from ‘conventional’ infor- blockchains ([Weer19]). Where the ‘traditional’ distrib-
mation systems. uted systems needed a trusted third party if transacting
participants wanted to exchange information, value or
Based on the relatively uniqueness of blockchain tech- goods without trusting each other, blockchains delegate
nology, this article will introduce some of the key risks this trust to the party’s participants themselves (i.e. end-
arising from the implementation of this technology in points); a trusted third party is no longer required.
existing IT environments and offer an impression on

56 How will blockchain impact an information risk management approach?

 This article is not intended to go into detail Permissioned blockchains are restricted access networks:
of how blockchain delegates trust to the the parties responsible for maintaining the network
participants (i.e. end points). However, to provide are able to determine who can access it and a restricted
some understanding, a more technical definition amount of parties are authorized to produce blocks
introduced by [Rauc18] is provided below. ([Cast18]) in the case of blockchains. Whereas permis-
sionless blockchains are open for anyone, accessing
“A blockchain system is a system of electronic permissioned networks requires approval from the
records that: authorised users of said network: “since only author-
1. enables a network of independent participants ized users are maintaining the network, it is possible to
to establish a consensus around restrict read access and to restrict who can issue transac-
2. the authoritative ordering of tions” ([Yaga18], p. 5).
cryptographically-validated (signed)
transactions. The likelihood of arbitrary or even malicious behaviour
3. These records are made persistent by on permissioned networks is smaller than on permis-
replicating the data across multiple nodes and sionless networks, as only authorized (thus, identified
4. is tamper-evident by linking them together by and trusted) users are able to access it. In case a user
cryptographic hashes. behaves malicious or not in the best interest of the entire
5. The shared result of the reconciliation/ network, access can be revoked by the parties main-
consensus process – the ledger – serves as taining the network. Although, malicious behaviour is
the authoritative version for these records” discouraged as a result of the network’s restricted access
([Rauc18], p. 24). and because a user’s identity needs to be determined,
consensus mechanisms may still be used to ensure “the
It is important to understand that there are countless ways same distributed, resilient, and redundant data storage
of designing a blockchain system. However, in the end, all system as a permissionless network (...), but often do not
blockchain systems are considered to have one primary require the expense or maintenance of resources as with
objective: to facilitate multi-party consensus whilst oper- permissionless networks” ([Yaga18], p. 5).
ating in an adversarial environment ([Rauc18]). That is, an
environment in which participants might not trust each Risks arising from blockchain
other or behave in such a manner that it is not in line with
the best interest of the overall system. Now that we have a basic understanding of blockchain
and how it differs from the more ‘conventional’ IT sys-
Permissioned versus permissionless tems, we can take a look at how blockchain technology
might affect existing information risk management
Broadly speaking, blockchains can be categorized “based approaches when it is implemented in existing organiza-
on their permission model, which determines who can tional IT environments. In order to keep this article brief,
maintain them” ([Yaga18], p. 5). The Bitcoin network can the author has selected the following set of key risks
be defined as a permissionless (public) blockchain as arising from blockchain that are worthwhile to address
anyone is able to produce a block (consisting of trans- (see Figure 1).
actions), read data that is stored on the blockchain and
issue transactions on this blockchain network. Since
the network is open for anyone to participate, malicious
users might be able to compromise the network. In order
Blockchain systems are
to prevent this, “permissionless networks often utilize
a multi-party agreement or consensus system that
considered to facilitate
requires users to expend or maintain resources when
attempting to produce blocks. This prevents malicious multi-party consensus
users from easily compromising the system” ([Yaga18],
p. 5). In the case of the Bitcoin blockchain, the Proof of while operating in an
Work consensus mechanism is used where block pro-
ducers are required to expend computational resources
in order to produce a block ([Naka08]). Other consensus
adversarial environment
mechanism examples include Proof of Stake (Ethereum),
Proof of Authority (Vechain) and Proof of Elapsed Time
(Hyperledger Sawtooth). Although designed differently,
all consensus mechanisms aim to discourage malicious
behaviour on the blockchain network ([Weer19]).

Compact 2019 4 Digital Auditing & Beyond 57

 sequences such as degraded data integrity or violated
privacy requirements due to the fact that personal data
is accessible, and the transaction commits cannot be
Compliance Consensus
& Network reverted (to adhere to the right to be erased/forgotten).
Sensitive personal data cannot be stored directly on
the blockchain, but rather ‘off-chain’ or on a ‘sidechain’
Third Party & 1 Cryptographic
10 (parallel blockchain), whereby the blockchain does not
Governance Key Management
contain personal data but points to the protected location
9 2 where that data is stored and can be removed if needed.

Risk domains Smart Contracts

Scalability Functional
& Continuity 8 arising from 3 requirements Smart contracts are agreements between blockchain
blockchain participants that are codified into the authoritative
ledger. The contract is executed automatically when
7 4 certain requirements (typically established by the par-
ties involved) are met. If smart contracts are incorrectly
Interoperability Smart
& integration
6 5 Contracts
designed, this might result in unintended and unfore-
seen consequences.
Data
Centralization Consensus & Network
Management
& Collusion
& Privacy Achieving consensus in a blockchain generally involves
a complex set of mathematical functions and coordina-
tion between the network nodes. In addition, in order to
ensure that the (majority of the) nodes exhibit honest
Figure 1. Domains where risks where might arise from using blockchain. behaviour, economic game theory needs to be considered
in the consensus process as well. If the consensus process
Scalability & Continuity is flawed, organizations transacting on this blockchain
Reaching consensus requires coordination and commu- might be exposed to significant risks – both operational
nication between nodes that are often spatially separated as financial.
from each other and located within the participant’s
internal IT environments. This might eventually result Compliance
in a lack of scalability or even threaten the continuity of The immaturity of blockchain technology is visible in
the blockchain system and the (business) process activi- the regulatory space as well, where laws and govern-
ties of organizations relying on the blockchain system. mental policies for applying and operating blockchain
technology are still in an embryonal stage. In addition,
Centralization & Collusion by its very nature, blockchains allow for the transacting
A blockchain is comprised of independent nodes. between parties that do not need to know or trust each
Although these nodes are operating independently from other. This exposes an organization to the risk of partici-
each other, these nodes might be owned by a single organ- pating in money laundering of terrorist financing.
ization or by a collaboration of organizations. Competitors
might be blocked from transacting on this system or risk Functional requirements
being restricted from using certain functionalities. Careful considerations should be made regarding the
decision to implement a blockchain; not only regarding
Interoperability the necessity of implementing a blockchain into an exist-
With the advent of blockchain adoption, interoperability ing IT environment, but also which type to select. Select-
between the technological generations may be a chal- ing or developing a blockchain that does not align with
lenge. A blockchain cannot simply be installed in the the organization’s business or operating model needs
existing IT environment of an organization as it must might have significant consequences for the organiza-
be connected to legacy IT systems, that usually have tion’s business activities that rely on the blockchain.
other compatibility limitations, or perhaps even to other
blockchains. Cryptographic Key Management
Blockchains employ cryptographic functions such as
Data Management & Privacy hashing algorithms and public key cryptography to
Any transaction proposal that is accepted to the ledger ensure the integrity of the overall system and guarantee
is considered final. Incorrect, incomplete or even unau- the safety. Improper management of cryptographic key-
thorized transactions might result in unintended con- pairs might result in unauthorized access of the system.

58 How will blockchain impact an information risk management approach?

Third Party & Governance
Where the effective operation of traditional IT systems
(i.e. every organization is the owner of their IT) primar-
ily relies on the control environment of the organiza-
tion itself, blockchains relies on both the overall control
environment of the network as well as the control envi-
ronments of the individual participating organizations.
One can argue whether ‘third parties’ in a blockchain
context are actually ‘second parties’. (See further the
box on blockchain governance.)

IMPACT OF BLOCKCHAIN ON
INFORMATION RISK MANAGEMENT

The field or information risk management is broad

in nature and extensively covered in both academics
and business. On a general level, information risk
management (IRM hereafter) can be defined as “the
application of the principles of risk management
Risks arising from
to an IT organisation in order to manage the risks
associated with the field” ([Tech14]). To support the
blockchain appear to
design of an effective IRM strategy, several standards
and approaches have been published that aim to help relate primarily to the
organizations in managing IT risks and designing an
IT control environment. Examples of these standards absence of a trusted
are the Handreiking Algemene Beheersing van IT-­
Diensten from NOREA, the ISO27001 framework from
ISO, the COBIT standard or the COSO management
third party or central
model.
authority
When we consider the abovementioned risks arising
from blockchain, it appears that these risks primarily
relate to the absence of a trusted third party or a central
authority: where current IT environments of organi-
zations can typically be thought of as centralized silos
(operated and managed by a single party) that are log-
ically separated from each other, blockchain powered
IT environments dissolve these boundaries as organiza-
tions transact on the same system.

Extending this development to information risk

management, with centralized IT environments, the
Information Risk Management organization is primar-
ily concerned with the internal control environment
surrounding their centralized IT environment. Gener-
ally, this control environment is sufficient to address
the risks arising from IT and facilitate the appropriate
operation of the IT environment.

However, when organizations implement blockchain

systems, they factually open up their IT environment to
third parties (perhaps also unknown parties or compet-
itors) that are not necessarily trusted by the organiza-
tion (i.e. the organization will operate in an adversary
environment).

Compact 2019 4 Digital Auditing & Beyond 59

 Taking a closer look at Libra 3. Furthermore, it is difficult for the governing mem-
bers to verify that the developing party exercises
If we look at this from a more practical perspective, let us its responsibilities in an objective manner and does
take a closer look at Facebook’s Libra initiative: a consor- not provide participants (e.g. Facebook) with a com-
tium of major organizations – i.e. Facebook, Spotify, Uber petitive advantage over other governing members,
and Vodafone – that develop their own blockchain with but also over organizations that are not part of the
the objective of operating as a global currency transac- network’s governance body.
tional model ([Libr19]). The following stakeholders are
involved in the management of the platform: In order to ensure that all stakeholders involved are
•• The Libra Association governs the network. comfortable with transacting on the Libra platform, the
•• Libra Networks LLC develops the software and infra- mentioned risks (not limited to) should be addressed first.
structure. It appears that addressing these risks i.e. designing an
•• The actual blockchain network consists of nodes ran effective information risk management strategy requires
by the individual Association members. multi-party collaboration and governance (see also the
•• Users (consumers and other organisations) can oper- box on a blockchain governance case).
ate on this network.
Governance considerations

The governance considerations of a platform

can make or break the success of not only your
organization’s implementation but the conti-
Platform
users nuity of the entire platform. An exemplary case
is the IBM and Maersk supply chain platform
TradeLens. In 2018, the companies announced
Transacting a joint venture to unify the shipping industry on
a common blockchain platform. The platform
was developed within a governance model that
put major decision-making power in the hands
Libra of the founders, allowing them to retain the
DLT
intellectual property of the shared platform and
forcing other logistical companies to invest sig-
nificantly in blockchain platform software. This
Governance Developing resulted in a reluctant reception and very limited
onboarding of other participants, limiting the
transaction volume via this platform. As a con-
Libra Libra sequence, the tipping point for success couldn’t
Develops on behalf of
Association Network LLC be reached. After restructuring the governance
model, other companies, such as CSX, PIL and
CEVA, decided to join.
Figure 2. Visualizing Libra’s actors and their relationships.
The correct governance model for your platform
is not a one-size-fits-all and depends on several
When we take a look at the relationship of the actors factors. These factors include, but are not limited
involved with Libra, one can argue that the key risks to:
relate to the inherent properties of the Libra blockchain • strategy and mission-criticality
and its multi-party transactional model are as follows: • policy/decision-making and risk sharing
1. Competitors are collaborating on the platform, but there • participant roles, responsibilities and
is no guarantee of fair play and a level playing field. representation
2. Node validators (organizations involved in the con- • node management
sensus process and validation of transactions taking • type and variety of international regulatory
place on the platform) have no access to each other jurisdictions
and it is therefore difficult for these organizations to • desired permission level of features
verify whether they are all adhering to the standards • cost of ownership, incl. financing and cost
and requirements set by the governing body (the charging
Libra Association) or whether they have an effective • supervisory bodies and assurance
operation of their control environments.

60 How will blockchain impact an information risk management approach?

 The IT audit will need
to stop treating IT
environments as singular

Risks Controls

Centralization & Collusion

Dynamic node participation might result in the risk of network exclusion Contractually enforce that the organization will host validator nodes of the
of participants network it operates on. At least one node should be owned when transacting
on a blockchain

Monitor network activities to determine which Public Key addresses (i.e. other
parties transacting on that blockchain) own validator nodes. If a participant’s
consensus power increases, proper escalation measures should be designed
and enforced.

Network participants might achieve majority control of blockchain The organization must contractually enforce that they will host validator nodes
network. This might violate the integrity of the network for each blockchain system it uses.

Blockchain participants contractually agree on the distribution of consensus

power to prevent one party from achieving majority control.

Monitor network activities to determine which Public Key addresses (i.e. other
parties transacting on that blockchain) own validator nodes. If a participant’s
consensus power increases, proper escalation measures should be designed
and enforced.

In case of permissionless networks, monitor the network to ensure that

centralization of the Validator power is identified appropriately.

Data Management & Privacy

The inherent nature of blockchains might result in GDPR (e.g. "right to be Establish data definitions and implement gatekeeper controls that ensure
forgotten") breaches confidential and sensitive information is not stored on the blockchain network.

Data might be input incorrectly or incompletely. The parties responsible for onboarding real-life object representations onto
the blockchain (‘Oracles’) are subject to an ISAE3000 / SOC2 audit and is
provided to the organisation that relies on such data.

Table 1. An extract of a blockchain risk and control framework.

AUDITING BLOCKCHAIN sortium and the individual participants with which

the organization transacts. Therefore, IT auditors need
To mitigate the risks arising from blockchain, organiza- to equip themselves with the capabilities of auditing a
tions are able to design control environments surround- governing network i.e. consortium and develop skillsets
ing their blockchain systems and business processes to properly assess multi-party risks.
transacting on those systems. To give you an example of
controls that might be designed, the author has included In the author’s opinion, IT auditors will extend their
a small part of controls intended to mitigate risks related focus to third party (smart) contracts, resolution models
to the Centralization & Collusion domain and the Data Man- and how consensus is configured – both from a technical
agement & Privacy domain introduced earlier. as well as an economic game theory perspective. The
IT audit will need to stop treating IT environments as
When we extend this to the field of IT audit, we might singular and start treating it as a risk ecosystem that is
consider the approach of an IT auditor to become less comprised of multiple actors.
singular and more driven from an ecosystem perspec-
tive. The IT auditor does not stop at the boundaries of the For further details on assessing and auditing blockchain
IT (control) environment of the organization; it extends implementations, please refer to [KPMG18] and [ISAC19].
to the control environment of the bigger network, con-

Compact 2019 4 Digital Auditing & Beyond 61

 References
The IT auditor will [Cast18]  Castellon, N. , Cozijnsen, P. & Goor, T.
van (2018). Blockchain Security: A framework
for trust and adoption. Retrieved from: https://
increasingly shift dutchblockchaincoalition.org/uploads/DBC-Cyber-
Security-Framework-final.pdf.

towards a consortium or [Delo19]  Deloitte (2019). 2019 Global Blockchain Survey.

Retrieved from: https://www2.deloitte.com/content/
dam/Deloitte/se/Documents/risk/DI_2019-global-
ecosystem auditor blockchain-survey.pdf.
[ISAC19]  ISACA (2019). Blockchain Preparation Audit
Program. Retrieved from: https://next.isaca.org/book-
store/audit-control-and-security-essentials/wapbap
[Kasi18]  Kasiderry, P. (2018). How Does Distributed
Consensus Work? Retrieved from: https://medium.
com/s/story/lets-take-a-crack-at-understanding-distribut-
ed-consensus-dad23d0dc95.
[KPMG18]  KPMG (2018). Blockchain Technology Risk
Assessment. Retrieved from: https://home.kpmg/xx/
CONCLUSION en/home/insights/2018/09/realizing-blockchain-poten-
tial-fs.html.
The topic of blockchain and its impact on information [KPMG19]  KPMG (2019). The Pulse of Fintech 2019.
risk management can be elaborated on and encompass Retrieved from: https://home.kpmg/xx/en/home/cam-
paigns/2019/07/pulse-of-fintech-h1-19-europe.html.
an entire book by itself. If organizations want to remain
in control of their blockchain-enabled IT environment, [Libr19]  Libra Association Members (2019). An
only to consider that the internal IT control environment Introduction to Libra.
is no longer sufficient: organizations need to start tak- [Naka08]  Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer
ing into account the control environment of the entire Electronic Cash System. Retrieved from: https://bitcoin.
org/bitcoin.pdf.
blockchain network, but also the internal control envi-
ronments of each participating organization acting as a [Rauc18]  Rauchs, M. et al. (2018). Distributed Ledger
Technology Systems: A Conceptual Framework.
node validator. The IT control environment of an organ- Retrieved from: https://www.jbs.cam.ac.uk/fileadmin/
ization implementing a blockchain therefore becomes user_upload/research/centres/alternative-finance/down-
an ‘ecosystem’ where its own control environment and loads/2018-10-26-conceptualising-dlt-systems.pdf.
information risk management strategy is dependent on [Stee16]  Steen, M. van & Tanenbaum, A.S. (2016). A brief
the control environments of the broader ecosystem and introduction to distributed systems, Computing, 98, 967-
its individual participants. In essence, the shift towards 1009.
distributed ledger technology results in a shift to distrib- [Tech14]  Techopedia (2014). IT Risk Management. Retrieved
uted control environments as well. from: https://www.techopedia.com/definition/25836/
it-risk-management.

Blockchain technology has the potential to digitize sup- [Weer19]  Weerd, S. van der (2019). An exploratory study on
the impact of multi-party consensus systems for infor-
ply chains, business processes, assets and transactions.
mation risk management.
How will the Information Risk Management organiza-
[Yaga18]  Yaga, D. et al. (2018). Blockchain Technology
tion and the IT auditor conduct their risk assessment?
Overview, NISTIR8202. Retrieved from: https://csrc.nist.
How can an effective control environment be designed gov/publications/detail/nistir/8202/final.
when organisations become part of digital ecosystems?
These are valid questions that ought to be resolved before About the author
organizations can think of harnessing the full potential Steven van der Weerd MSc  started as a consultant
of blockchain technology. The author is convinced that with KPMG IT Assurance & Advisory in 2015. He has
performed numerous audit and advisory engagements
the Information Risk Management professional and IT within the financial services sector. He focuses on
auditor have an exciting future ahead of them and are financial markets with an emphasis on the banking,
able to provide a great contribution in helping transform payments and leasing sectors. He is specialized in IT
organizations in an appropriate and controlled manner. audit innovation and developing information risk
management approaches for (emerging) technologies,
with a specific emphasis on blockchain technology.
He is also involved in KPMG’s Blockchain taskforce
and in NOREA’s Knowledge Group on Supply Chain
Digitisation focused on blockchain controls.
The author likes to thank Raoul Schippers for his addition on
blockchain governance.

62