A Primer for Information Technology General Control Considerations on a Private and Permissioned Blockchain Audit Free

Blockchain has been described as a disruptive technology, with the potential to impact business and society in ways not seen since the Internet (D. Tapscott and A. Tapscott 2016; Casey and Vigna 2018). Specific to the audit profession, blockchain provides an immutable ledger and the opportunity to test full populations of transactions, possibly in real-time (Diedrich 2016; Dai and Vasarhelyi 2017; Zhang, Pei, and Vasarhelyi 2017). As such, the technology has attracted much attention, including from the Big 4 accounting firms who are actively preparing for blockchain advisory and assurance service offerings (Deloitte 2017; Kokina, Mancha, and Pachamanova 2017; KPMG 2017; EY 2018; PwC 2018). This focus on blockchain from major firms highlights the importance for the audit community to stay informed about the technology, particularly from an assurance perspective (AICPA and CPA Canada 2017; Deloitte 2017; Smith 2018a). In this paper, I provide a primer on new information technology general control (ITGC) areas of focus that external auditors should consider when evaluating clients' private and permissioned blockchains as a part of audits of internal control over financial reporting (ICFR).¹ I focus on ITGCs because they help establish whether a blockchain operates in a controlled environment, which affects the reliability of blockchain-generated data (including data to be used as part of an audit) (AICPA and CPA Canada 2017). I end by discussing ITGC risks that blockchain could eliminate and propose several points of caution for auditors.

Please note that it is not the aim of this paper to explain the intricacies of a blockchain. Readers that seek a broader discussion of the technology should see Dai and Vasarhelyi (2017), who address blockchain structure and functionality. However, in Appendix A, I offer a glossary of blockchain terms used throughout this paper.

There are many definitions of blockchain now available, and it will take some time until the academic, corporate, and technology communities settle on a single definition.² One way to categorize blockchains is by the visibility of the underlying ledger and the openness of access rights. The extant literature is yet to agree on terms used to categorize blockchains in this way, but the most common approach is to label a blockchain as either (1) private or public, or (2) permissioned or permissionless (e.g., Coyne and McMickle 2017; Dai and Vasarhelyi 2017; Rückeshäuser 2017; Bauerle 2018). I follow Drescher (2017) and use a combination of these categories to focus this study on private and permissioned blockchains. Here, only authorized users can view the ledger of historic transactions (private blockchain), and only authorized users/nodes can participate in submitting/relaying/verifying transactions and validating new blocks (permissioned blockchain).³ Private and permissioned blockchains are likely to be the first adopted into the mainstream business environment (AICPA and CPA Canada 2017; Drescher 2017; Smith 2018b), and can exist within a single organization or span a consortium of organizations.⁴ In this study, I discuss private and permissioned blockchains that exist in an organization that is part of a blockchain consortium (e.g., a supply chain).

A blockchain has features that allow it to act like both an application and a database (Diedrich 2016). As such, while the purpose of this paper is to present additional ITGC areas of focus that auditors should consider specific to blockchains, auditors should still address other areas of focus that are applicable across technologies. Further, it is not reasonable to believe that organizations will completely abandon their existing information technology (IT) infrastructures and replace these with a blockchain (nor could a blockchain accomplish all the necessary tasks across an IT function). Rather, it is likely that organizations will slowly start to implement blockchains in certain parts of their business, meaning that the blockchain will have to exist alongside legacy and enterprise resource planning (ERP) systems. For this paper, a blockchain can therefore be viewed as a tool inserted into an existing IT infrastructure that receives inputs from upstream systems (e.g., a sales system), performs some processing and data recording, then makes data available to downstream systems (e.g., a general ledger system) for aggregation and/or reporting purposes. Figure 1 provides a visualization of this configuration.

ISACA provides a guide on best practices to address IT internal controls on ICFR audits: IT Control Objectives for Sarbanes-Oxley: Using COBIT 5 in the Design and Implementation of Internal Control Over Financial Reporting, 3rd Edition (the “Guide”) (ISACA 2014). The Guide is informed by authoritative standards and prominent internal control frameworks, including: the Public Company Accounting Oversight Board's (PCAOB) Auditing Standard No. 5, the American Institute of Certified Public Accountants (AICPA) Auditing Standards Board's (ASB) Statement on Standards for Attestation Engagements No. 16, the Committee of Sponsoring Organizations of the Treadway Commission's (COSO) 2013 Internal Control—Integrated Framework, and ISACA's COBIT 5 control framework (ISACA 2014). While the PCAOB does not require auditors to apply a specific internal control framework when evaluating business or IT controls, “most of the larger accounting and auditing professional firms and consultants created their internal control and audit templates from the second edition” of the Guide (ISACA 2014, 11). As such, I follow the Guide and categorize ITGCs into the following domains: Program Development and Change Management, Computer Operations, and Access to Programs and Data.⁵ Consistent with the Guide, I also address the overall IT control environment. Within this framework, I discuss new areas of focus that auditors should consider on audits of private and permissioned blockchains used by a consortium of organizations, as well as some risks that blockchains could eliminate.⁶

The use of blockchain does not change the fact that organizations need strong IT governance in place. However, with a blockchain consortium, this governance becomes more complex as auditors need to consider the controls that exist in and around the consortium. To begin, auditors should consider if the consortium has a steering committee in place, the powers granted to this committee, and the voting power of each member. Further, auditors should understand the resources committed by each member (financial, personnel, or computational), and what evidence members provide to demonstrate that proper controls are implemented and maintained across the blockchain (effectively, ITGCs in place at each member organization). Evidence of proper controls might come from an independent attestation, similar to what is available with the system and organization control (SOC) framework as rooted in the AICPA's Statements on Standards for Attestation Engagements No. 18, Attestation Standards: Clarification and Recodification. Auditors should also evaluate the consensus protocol to understand which nodes are authorized to participate in consensus, the distribution of computational power among members, and the underlying approach to consensus (e.g., proof-of-work; proof-of-stake; all nodes validate all blocks and consensus is reached when a majority agree on the current state) (Buterin 2015; AICPA and CPA Canada 2017). In doing so, auditors should consider whether the balance of computational power among validating nodes would allow a single node (or small concentration of nodes) to perpetrate fraud or malicious activities through a 51 percent attack on the blockchain (Rückeshäuser 2017).

Areas of focus for Program Development and Change Management are closely related, and are therefore discussed together in terms of Change Management.⁷ Changes to systems require a controlled process to request, develop, test, authorize, and implement the update. With blockchain, changes can occur with the consensus protocol, communication protocol, smart contracts, decentralized applications (Dapps), or the underlying source code of the chain. Changes to the source code and protocols require the chain to pause while updates load. Changes to smart contracts or Dapps are submitted through transactions, become permanent programs on the blockchain, and are virtually unstoppable once loaded (Diedrich 2016).⁸ Further, changes to smart contracts might involve a change in the referenced oracle, so auditors should consider whether any changes to the oracle are properly linked to the smart contract (AICPA and CPA Canada 2017). Finally, consortiums should have a mechanism in place to ensure that all members agree with, and implement, changes. This might involve a change management committee with elected representatives or one official from each member organization. Agreement on changes is critical, as consortiums run the risk that not all members accept and implement changes, which could result in a fork to the chain. As such, auditors should consider a client's approach to ensure that all consortium members approve and implement changes. Figure 2 provides a visualization of the changes in a blockchain that auditors need to consider.

Specific to Program Development, auditors should also consider the approach used to migrate data from a retired system to the blockchain. It seems unlikely that clients will take complete historical data from a retired legacy system(s) and enter it into the blockchain as part of a genesis block, particularly if it is a significant amount of data. A more likely scenario involves clients beginning to record new transactions to the blockchain as of a specific date (possibly starting with current account balances), while maintaining a separate archive of historical data from retired legacy systems up through the date of blockchain implementation.⁹

As previously discussed, as organizations begin to incorporate private and permissioned blockchains, there will likely be a transition period during which legacy systems, ERPs, or even third-party cloud-based systems will perform front-end processing and data collection. These systems will then interface with a blockchain for additional processing or recording. Such a setup makes it important to maintain (or even enhance) existing policies and procedures over legacy applications and processes, as these will generate data that is ultimately loaded into the blockchain. While data is (largely) tamper-proof once in a blockchain, that data is still vulnerable to common IT risks while outside the blockchain. The interface transmission of data from upstream systems to a blockchain will be one of the most sensitive control points in these new environments. At least initially, these transmissions might be best suited to occur as part of scheduled batches, as there is a clear record of the data released from upstream systems and then captured by the blockchain. Auditors will need to work with their clients to determine how this transition can happen in the most controlled manner given the client's unique IT environment.

Another way for data to enter the blockchain is through third-party software oracles or Internet of Things (IoT) devices (i.e., hardware oracles) that inform the execution of smart contracts. Devices such as radio-frequency identification (RFID) tags connect activity in the physical world to smart contracts on a blockchain (Dai and Vasarhelyi 2017). For example, a supply chain blockchain might rely on RFID tags connected to physical assets to serve as hardware oracles to inform smart contracts when specific goods have departed or arrived at designated locations. In the cases of both software and hardware oracles, auditors will want to evaluate the client's procedures used to determine whether the oracle is free from bugs or embedded code that could compromise the integrity of data before it enters the blockchain (e.g., whether the client obtains periodic evidence about safeguards used to secure third-party oracles).¹⁰ Further, oracles should be properly linked (logically) to smart contracts, and smart contract logic should be evaluated for appropriateness. Auditors should also evaluate the physical control of IoT devices used as hardware oracles, specifically the procedures used to implement, modify, or retire these units.

Finally, while blockchain helps alleviate many concerns over business continuity/disaster recovery (BC/DR) planning (for data on the blockchain), auditors will want to evaluate whether BC/DR plans consider the procedures to follow when blockchain-interfacing legacy systems become unavailable. Specifically, while data should not be lost on the blockchain, clients still need to plan for BC/DR scenarios when the blockchain relies on data or inputs from compromised upstream legacy systems.

Auditors will need to evaluate user/node access provisioning (grant, modify, remove) with a specific focus on blockchain. The most sensitive component of access considers those with permission to submit, relay, or verify transactions as well as validate new blocks. This should be a selective group of users/nodes who gain access via a formal request and approval process, and are then subject to a periodic review or reconfirmation of access rights. Further, auditors will need to understand and evaluate the consortium's agreement regarding who should have access to manipulate smart contracts, Dapps, underlying protocols (i.e., consensus and communication protocols), and blockchain source code (cf. AICPA and CPA Canada 2017). Auditors should also evaluate the parties in the consortium that are able to provision access (e.g., one administrator elected by the consortium, or one administrator from each member organization to handle local changes). Finally, auditors will want to determine that users who no longer require access have these rights revoked in a timely manner (i.e., for voluntary departures, involuntary departures, or changes in job function).

If the consortium uses private keys to transfer digital assets on the blockchain, auditors should evaluate the process to store these private keys (Berke 2017).¹¹ A common problem with cryptocurrencies is that users who lose their private key can no longer access the digital assets associated with their public key account; private keys are not like passwords that can be reset.¹² As such, if a consortium uses public and private keys to control the movement of digital assets on the blockchain, auditors should consider the process in place to store these keys or regain control of the associated assets in the event a private key is lost or compromised (Berke 2017). Auditors should also consider the security of assets associated with private keys if an employee no longer requires access to the associated assets.

Finally, blockchains increase the need for robust network security. While network security might have fallen “out-of-scope” on some ICFR audits of the past, concerns over access to the ledger, transactional data, and smart contracts (among others) result in a need for increased scrutiny (i.e., a “scoping-in”) of the supporting network.¹³

A blockchain has the potential to minimize or eliminate several risks related to Computer Operations. First, most organizations have internal controls and processes in place to incrementally backup data. With blockchain, there is no longer a need to perform data backups (for data recorded on the blockchain) because the data is stored in a permanent ledger. Even if one node is compromised, the remaining nodes maintain the full ledger and a copy of the underlying source code and related protocols (Diedrich 2016). Within the blockchain, there is also not a need to schedule the release of transactions as with batch processing. Rather, transactions will be processed and recorded in near real-time as determined by the communication and consensus protocols. Finally, blockchain has much to offer in terms of disaster recovery. Similar to the point made about data backups, a geographically dispersed blockchain helps protect against potential disasters (e.g., hurricane, fire, tornado) as the non-impacted nodes will continue running the blockchain and will maintain the integrity of the ledger. Once the issue has passed, the impacted nodes can rejoin the blockchain and download the current state (Diedrich 2016). Therefore, as long as a consortium blockchain is not limited to nodes at a single site, recovery procedures of the blockchain itself might become obsolete.

Within Access to Programs and Data, blockchain helps minimize concerns over the ability to modify or delete historical data. Once a block is sufficiently buried (i.e., once newer blocks are validated on top of it), there is minimal risk of changes to historical data on a blockchain, unless the consortium collectively agrees to the change (Diedrich 2016; Drescher 2017). As such, additional controls to protect recorded data are not necessary due to the inherent design of blockchains that makes this data (largely) immutable.

Table 1 provides a summary of the areas of focus from the IT Control Environment and ITGC domains, the additional considerations for a blockchain audit, and the concerns possibly eliminated by a blockchain.

It is important for blockchain users (i.e., businesses, auditors, regulators) to remain vigilant. The secure processing, immutable ledger, and resiliency offered by a blockchain should not mask the fact that it is still just one component of an IT infrastructure, and thus requires the support of properly functioning ITGCs. Without effective ITGCs, the data produced by a blockchain might not be reliable (AICPA and CPA Canada 2017). Further, poorly designed queries of the blockchain might result in datasets that are not complete and accurate, which is further complicated by the fact that not all of the data might reside on the blockchain (Drescher 2017). As such, users who make decisions based on data extracted from a blockchain should be careful to understand how that data is controlled, queried, and how they are comfortable that the extract covers the intended scope (i.e., accounts, events, time period). Auditors, specifically, should consider this point when they intend to use blockchain extracts to perform full population testing of transactions. Further, if organizations depend on smart contracts or smart controls to act like automated application controls, there need to be effective ITGCs in place to support reliable application processing (Norman, Payne, and Vendrzyk 2009; Huang, Hung, Yen, Chang, and Jiang 2011). The continued proper functioning of these smart contracts and smart controls depends on a secure ITGC environment and robust processes to make any changes to the underlying logic or functionality.

Finally, while not ITGC-specific, auditors should remind clients that blockchain is not the solution for every scenario. Clients should be confident that they require the added benefits of blockchain that extend beyond a shared database or ERP system. For the time being, blockchain is an evolving technology, and clients should be cognizant of the tradeoffs between being an early blockchain adopter versus using a proven and mature technology solution.

The unique implementation of a private and permissioned blockchain requires special ITGC considerations. This paper addressed new areas of focus in terms of the IT Control Environment, Program Development and Change Management, Computer Operations, and Access to Programs and Data (ISACA 2014). However, blockchain also provides some ITGC relief as it minimizes risks related to modifications to historical data, the need for data backups, batch processing amongst nodes, and disaster recovery of data and programs on the blockchain. This paper serves as a primer for ITGC considerations on private and permissioned blockchain audits that involve ICFR, and more nuanced concerns are likely to emerge as the technology matures and use cases shift. Still, it is important to address these topics now to prepare the auditing community for the disruption of blockchain.

• Blockchain—There are many definitions of blockchain, and it will take some time until the academic, corporate, and technology communities agree on a single definition. Casey and Vigna (2018, 64) offer an encompassing definition of blockchain as “a distributed, append-only ledger of provably signed, sequentially linked, and cryptographically secured transactions that's replicated across a network of computer nodes, with ongoing updates determined by a software-driven consensus.”

• Communication protocol—The rules for how nodes are to communicate and share information.

• Consensus—Occurs when nodes agree on the same current state (Diedrich 2016).

• Consensus protocol—The rules followed by nodes to confirm previously verified transactions and to verify new transactions and blocks (Berke 2017).

• Current state—Based on the history of transactions, what a node believes to be present truth (Diedrich 2016).

• Decentralized application (Dapp)—Applications for which the back-end source code is stored (at least partially) on the blockchain. User interfaces (i.e., the front-end) are still provided by centralized servers (Diedrich 2016).

• Fork—When nodes are not in consensus about the current state, they might split and form groups that agree on a common transaction history and current state (Diedrich 2016).

• Genesis block—The first block in a blockchain (Drescher 2017).

• Hash—An algorithm that takes data files of any size and turns these into equal-length stings of letters and numbers (Drescher 2017).

• Node/Validator node—One computer on a blockchain network that runs a client to verify transactions, relay transactions, and validate new blocks on the chain (Swan 2015; Diedrich 2016; Monax 2018).

• Oracles—Provide information to smart contracts from outside the blockchain (Diedrich 2016). There are different types of oracles. Software oracles push information available online to smart contracts (e.g., temperature in a specific city), while hardware oracles push information that originates from the physical world (e.g., RFID tags used in supply chains) (BlockchainHub 2018). Some entities elect to use the consensus of several oracles to determine the true outcome of an event (BlockchainHub 2018).

• Proof-of-work—Nodes compete to solve a hash puzzle to add new blocks to the blockchain. This involves hashing the transactions to be included in a new block together with a nonce (i.e., a random number), such that the resulting hash string begins with a pre-determined number of zeros (Diedrich 2016; Drescher 2017).

• Proof-of-stake—Cryptocurrency owners/holders are assigned to verify new transactions and blocks based on their respective percentage of ownership, and thus do not compete to validate each new block (Coyne and McMickle 2017; Kokina et al. 2017).

• Smart contract—A binding contract written in code and stored on a blockchain that automatically executes once pre-determined criteria are met (Diedrich 2016; Tapscott and Tapscott 2016; Drescher 2017). For example, if I agree to pay you $10 if the price of oil reaches $100 a barrel, this contract will automatically execute once a predetermined oracle confirms that oil has reached $100 a barrel.

• Smart controls—The use of smart contracts to establish automated controls within the blockchain (Dai and Vasarhelyi 2017).

• System and Organization Controls (SOC)—Suite of attestation reports developed by the AICPA that address internal controls used by service organizations to deliver business or IT functions to user organizations (AICPA 2018).

• 51% attack—When a node, or several colluding nodes, accumulate more than 51% of the computing power on a blockchain with the intent to establish a new chain history (see “fork” above) that reverses or does not recognize previously verified transactions (Swan 2015; Drescher 2017; Rückeshäuser 2017).