US20190132350A1

US20190132350A1 - System and method for validation of distributed data storage systems

Info

Publication number: US20190132350A1
Application number: US16/175,715
Authority: US
Inventors: Alfred Michael SMITH; Muhammad Emad KHAN
Original assignee: PricewaterhouseCoopers LLP
Current assignee: PWC Product Sales LLC
Priority date: 2017-10-30
Filing date: 2018-10-30
Publication date: 2019-05-02
Also published as: WO2019089646A1; US10915641B2; WO2019089654A1; US20190130114A1

Abstract

Provided herein is a risk framework tool for a distributed ledger-based computing system (i.e., blockchain) that can present a common risk framework to a user that can then allow for the user to determine what risks are important for it to manage. The risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization's blockchain system. In one or more examples, the risk framework can provide a graphical user interface to user that allows them specify the risks they wish to manage within the blockchain computing system, and based on the user's inputs, can determine one or more continuous real-time validation tests to be performed on the blockchain computing system so as to characterize the risk specified by user using the risk framework.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/579,093, filed Oct. 30, 2017, and U.S. Provisional Patent Application Ser. No. 62/579,095, filed Oct. 30, 2017, each of which are incorporated herein by reference in their entirety and for all purposes.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to validation of distributed data storage systems, such as, for example, blockchain-based data storage systems.

BACKGROUND OF THE DISCLOSURE

A distributed data storage (which may be referred to as a distributed database) system may include data storage devices that are not connected to a common processing unit, but are in different computing systems located at the same physical location or dispersed across one or more networks of interconnected computing systems at different physical locations. The data storage devices may communicate with each other via one or more wired or wireless communication networks. Typically, each of the data storage devices includes a copy of the stored data. Storing copies of the data in different data storage devices may eliminate a single point-of-failure and may induce both higher availability and increased reliability of the stored data.
Blockchain technology may be used to implement a distributed data storage system. In the blockchain technology, a system of networked nodes, e.g., computers or servers, each store a copy of the entire distributed data storage system. The blockchain-based distributed data storage system is often referred to as a blockchain. Whenever a group of data records is to be added to the distributed database, i.e., blockchain, each node may independently verify the group of data records in a batch process known as generating a block (also referred to as a data block). In the batch process, a node verifies the group of data records based on its copy of the blockchain storing previously verified data records. A node that generates the block may transmit the generated block to every other node in the system. In current implementations, only after the block has been verified by each node in the system may each node add the block to its copy of the blockchain. As each of the nodes independently verifies the block, blockchain technology may reduce the risk of a single point-of-attack or a single point-of-failure. Further, since a copy of the blockchain is maintained at each node, the data can be stored in a redundant manner.
A blockchain is a record of data activities. These data activities can be transactions in a distributed ledger, and/or any movement of money, goods, and/or secured or unsecured data involved, for example, in a purchase at a supermarket, in the creation and storage of a user's digital identification, in the assignment of a government ID number, in energy data exchange in the energy industry, in an e-voting service, or in the recording, tracking, and transferring of deeds and contractual agreements.
FIG. 1 illustrates a blockchain process flow in accordance with examples of the disclosure. The blockchain process flow 100 can begin at step 102, wherein a user/party can request to implement a transaction in the blockchain. Examples of transactions can be storing data such as a record to a distributed ledger. Once the request has been made at step 104, the transaction can be broadcast to other computers (known as nodes) in the network. At step 106, the network of nodes can then validate the transaction using a mutually a priori agreed upon algorithm. Once each node in the network of nodes validates the transaction, the process can move to step 108, wherein the verified transaction can be combined with other transactions (described in detail below) to create a new block of data for the ledger. Once the verified transaction has been combined, the process can move to step 110 wherein the new block can be added to the network's block chain. The new block can be added in such a way as to make it permanent and unalterable (i.e., through the use of cryptography). Once the new block has been added the process can move to step 112 wherein the transaction is completed.
As shown in FIG. 1, a blockchain needs to do two things: gather and order data into blocks, and then chain them together securely using cryptography. A blockchain is a decentralized ledger of all transactions in a network. Using blockchain technology, participants in the network can confirm transactions without the need for a trusted third-party intermediary.
FIG. 2 illustrates the process of generating a data block in a blockchain in accordance with examples of the disclosure. In the process 200, a piece of digital content (i.e., a new transaction represented in binary) can be received. Once received, the process can move to step 204 wherein a hash function is applied to the received transaction, so as to combine it with data from a pre-existing block in the blockchain. The output of the hash function can produce a fixed and smaller-in-length unique digital output. Hash algorithms can carefully designed to flow one-way making it impossible to determine the original digital content from the output once the hash algorithm is applied. Every new block in the blockchain may be linked with the hash function of the previous block to create a chain. At step 206, once the has function has been applied, an output can be generated. The output of the hash function can be a part of the data that is used in the creation of blocks, and these blocks can then cryptographically chained together at step 208. This process of creating blocks allows the blockchain system to prove that a file existed in a particular format at a given time without having to reveal the data in the file.
One of the benefits of blockchain is that every participant in the network has simultaneous access to a view of the information, thus allowing almost real-time data availability and transparency that can eliminate the need for reconciliation. Also, the integrity and security of the information on the blockchain are ensured with cryptographic functions that can prevent unwanted intrusion on the network from non-authenticated participants. In blockchain technology, verification can be achieved by participants confirming changes with one another, thus replacing the need for a third party to authorize transactions and providing a facility for peers in the network to validate updated information, thereby ensuring the validity and integrity of the data on the blockchain. Another benefit of blockchain includes the ability to run additional business logic; this means that agreement on the expected behavior of financial instruments can be embedded in the blockchain, which can facilitate the ability to design and implement shared workflow and enhance automation. Also, the ability to issue a digital currency or a digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units facilitates the ability to create and move assets without a trusted third party in the blockchain.

SUMMARY OF THE DISCLOSURE

Blockchain presents a challenge to the traditional validation (also referred to as audit) approach, given there's no practical way to use point-in-time forensic analysis—the standard validation tool. Attempting to conduct a point-in-time forensic retrospective analysis can be ineffective and wildly inefficient. The conventional approach to auditing can negate one of the benefits of implementing blockchain in the first place: the promise of increased administrative efficiency. Also, the traditional validation approach can require the entire blockchain hash function to be reversed to obtain transparency of the digital content without breaking the chain or sequential order of the blocks. Such approach could cause significant technical complexities, challenges, and inefficiencies in the validation of a blockchain-based data storage system.
Increases in the volume of data activities and rapidly evolving complex technologies are creating a critical need for business, technology, and compliance functions to be prepared, adaptive, and agile to emerging challenges. Due to the increase in data activities, current validation methodologies that are manual, sample-based, and point-in-time do not provide the needed level of confidence. Validation methodologies need to shift from a manual to an automated and continuous approach to address a significant increase in data activities and emerging, complex new technologies. Current audit methodologies cannot provide the necessary assurance in areas where a blockchain is used.
Accordingly, there is a need for systems and methods to replace the conventional validation approach with a real-time validating process to build confidence and assurance in the blockchain technology. The concept behind real-time validating is to inspect data activities closer and closer to the point of occurrence. Real-time validating eliminates the concept of sampling in the conventional validating process. The purpose of sampling is to perform backwards-looking assessments of segments of populations to draw conclusions about the rest of the population. The embodiments described herein provide blockchain assurance-related baselines that eliminate the need for sampling in blockchain validating.
The type of validation and auditing required for a given a distributed ledger-based system such as blockchain can be user specific. No two organizations may need the same validation regime to audit its blockchain system. Often times, various risks and concerns may be important in one context, but not as critical in others. Therefore, there is a need to specify the types of tests that will be used based on a specific user/organization's risk priorities. The present disclosure thus provides a common risk framework that can allow for a user to conveniently determine what risks are important for it to manage. The risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization's blockchain system. The risk framework can thus be used to customize a software tool that can then be used to perform real-time validation of an organizations blockchain computing infrastructure and system.
In some embodiments, a validation tool/system for any given blockchain use case may include tools for monitoring and validating of data activities (also referred as transactions) in one or more data blocks of the blockchain, risk evaluation of the data activities, business and technical risk and reporting assessments, and software that enables transaction level assurance for operational processes running on any given blockchain use case. The continuous assurance, compliance, monitoring, and validating methodology may be a combination of services and software intended to provide transparency in meeting the assurance and compliance needs of stakeholders. In some embodiments, the continuous assurance, compliance, monitoring, and validating of blockchains may be based on an acceptance criteria. In some embodiments, the acceptance criteria may include evaluating the current state of a blockchain use case against different risk categories (e.g., six or more different risk categories) and across sub-categories (e.g., 100 or more different sub-categories) in order to address assurance and compliance needs of stakeholders. This evaluation may be performed by a risk evaluation system that is industry, use case and Blockchain platform agnostic.
In some embodiments, a method for validating a blockchain-based data storage system is provided. The method comprising: conducting a risk analysis of using the blockchain-based data storage system in a specified environment; generating a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determining a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; performing the validity test on the one or more data activities; and generating one or more validity test reports based on output of the validity test.
In some embodiments of the method, further comprising: displaying a user interface for selecting one or more test parameters of the validity test for testing compliance of the one or more data activities with the operating protocol of the blockchain-based data storage system; receiving from a user using the user interface one or more selections of the one or more validity test parameters based on the risk profile; and configuring the validity test based on the selection of the one or more validity test parameters.
In some embodiments of the method, the conducting the risk analysis comprises determining one or more risk categories of one or more risks involved in using the blockchain-based data storage system in a specified environment
In some embodiments of the method, the validity test is selected based on the risk categories.
In some embodiments of the method, the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.
In some embodiments of the method, the one or more data activities comprise storing one or more data in the data block.
In some embodiments of the method, the performing the validity test comprises performing the validity test continuously on the stored one or more data.
In some embodiments of the method, the generating the one or more validity test reports comprises: receiving from the user using the user interface a selection of one or more time periods within the one or more validity test; analyzing the output of the validity test during the one or more time periods; and generating the one or more validity test reports at end of each of the one or more time periods.
In some embodiments of the method, the performing the validity test comprises displaying, using the user interface, the output of the validity test; and wherein, in response to the output indicating that the one or more data activities failed the validity test, receiving from the user using the user interface a selection of whether the one or more data activities are exceptions to the operating protocol of the blockchain-based data storage system.
In some embodiments, a system comprising one or more processors and a memory comprising one or more programs, which when executed by the one or more processors, cause the one or more processors to: conduct a risk analysis of using the blockchain-based data storage system in a specified environment; generate a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determine a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; perform the validity test on the one or more data activities; and generate one or more validity test reports based on output of the validity test.
In some embodiments of the system, the one or more processors are further caused to: display a user interface for selecting one or more test parameters of the validity test for testing compliance of the one or more data activities with the operating protocol of the blockchain-based data storage system; receive from a user using the user interface one or more selections of the one or more validity test parameters based on the risk profile; and configure the validity test based on the selection of the one or more validity test parameters.
In some embodiments of the system, the one or more processors are caused to determine one or more risk categories of one or more risks involved in using the blockchain-based data storage system in a specified environment
In some embodiments of the system, the validity test is selected based on the risk categories.
In some embodiments of the system, the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.
In some embodiments of the system, the one or more data activities comprises storing one or more data in the data block.
In some embodiments of the system, the validity test is performed continuously on the stored one or more data.
In some embodiments of the system, the one or more processors are caused to: receive from the user using the user interface a selection of one or more time periods within the one or more validity test; analyze the output of the one or more validity tests during the one or more time periods; and generate the one or more validity test reports at end of each of the one or more time periods.
In some embodiments of the system, the one or more processors are caused to display, using the user interface, the output of the validity test; and wherein, in response to the output indicating that the one or more data activities failed the validity test, the one or more processors are caused to receive from the user using the user interface a selection of whether the one or more data activities are exceptions to the operating protocol of the blockchain-based data storage system.
In some embodiments, a non-transitory computer-readable storage medium storing one or more programs for validating a blockchain-based data storage system, the one or more programs configured to be executed by one or more processors and including instructions to: conduct a risk analysis of using the blockchain-based data storage system in a specified environment; generate a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determine a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; perform the validity test on the one or more data activities; and generate one or more validity test reports based on output of the validity test.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a blockchain process flow in accordance with some embodiments.

FIG. 2 illustrates generation of a data block in a blockchain in accordance with some embodiments.

FIG. 3 illustrates shift in validating and control processes in distributed data storage systems in accordance with some embodiments.

FIG. 4 illustrates steps of a validation method for validating data activities in a data block of a blockchain data storage system in accordance with some embodiments.

FIG. 5A illustrates a correspondence of the risk framework testing procedures to a technology stack of a blockchain system according to examples of the disclosure.

FIG. 5B illustrates sub-categories corresponding to each risk framework category according to examples of the disclosure.

FIG. 6 illustrates an exemplary process for generating blockchain test procedures according to examples of the disclosure.

FIG. 7 illustrates an example of a computing device in according to examples of the disclosure.

Illustrative embodiments will now be described with reference to the accompanying drawings. In the drawings, like reference numerals generally indicate identical, functionally similar, and/or structurally similar elements.

DETAILED DESCRIPTION

Embodiments of the present disclosure may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the present disclosure may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices, and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.
The embodiments described herein may be implemented within a local computer system. The computer system may be implemented in the contexts of the likes of computing systems, networks, servers, or combinations thereof. The computer system includes one or more processors and main memory. Main memory may store, in part, instructions and data for execution by processors. Main memory stores the executable code when in operation, in this example. The computer system may further include a mass data storage, a portable storage device, output devices, user input devices, a graphics display system, and/or peripheral devices.
The components of the computer system may be connected to a communication infrastructure (e.g., a bus or network). Processors and main memory may be connected via a local microprocessor bus, and the mass data storage, peripheral device(s), portable storage device, and graphics display system may be connected via one or more input/output (I/O) buses.
Mass data storage, which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor. Mass data storage may store the system software for implementing embodiments of the present disclosure for purposes of loading that software into main memory.
Portable storage device may operate in conjunction with a portable non-volatile storage medium, such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device, to input and output data and code to and from the computer system. The system software for implementing embodiments of the present disclosure may be stored on such a portable medium and input to the computer system via the portable storage device.
User input devices can provide a portion of a user interface. User input devices may include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. User input devices can also include a touchscreen. Suitable output devices include speakers, printers, network interfaces, and monitors.
Graphics display system may include a liquid crystal display (LCD) or other suitable display device. Graphics display system may be configurable to receive textual and graphical information and processes the information for output to the display device.
Peripheral devices may include any type of computer support device that adds additional functionality to the computer system.
The components provided in the computer system are those typically found in computer systems that may be suitable for use with embodiments of the present disclosure and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system can be a personal computer (PC), hand held computer system, telephone, mobile computer system, workstation, tablet, phablet, mobile phone, server, minicomputer, mainframe computer, wearable, or any other computer system. The computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID, IOS, CHROME, TIZEN, and other suitable operating systems.
The processing for various embodiments may be implemented in software that is cloud-based. In some embodiments, the computer system described above may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, the computer system may itself include a cloud-based computing environment, where the functionalities of the computer system are executed in a distributed fashion. Thus, the computer system, when configured as a computing cloud, may include pluralities of computing devices in various forms.
The cloud may be formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the computer system, with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers may manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be coupled with the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
While various embodiments have been described below, it should be understood that they have been presented by way of example only, and not limitation. The descriptions are not intended to limit the scope of the invention to the particular forms set forth herein. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the exemplary embodiments described herein. It should be understood that the description is illustrative and not restrictive. To the contrary, the present descriptions are intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims and otherwise appreciated by one of ordinary skill in the art.
Blockchain validation tool/system (may be referred as Blockchain Continuous Assurance, Compliance, Monitoring and Validating Solution or Blockchain Continuous Validating Solution) can include a Continuous Assurance, Compliance, Monitoring and Validating Methodology (may be referred as continuous validating methodology), Continuous Assurance, Compliance, Monitoring and Validating Criteria (may be referred as blockchain validating criteria or acceptance criteria), blockchain risk evaluation system (may be referred as blockchain risk framework), business and technical risk and reporting assessments, and software that enables transaction level assurance for any given Blockchain use case. The validation system can include a combination of services and software designed for practitioners to provide transparency in meeting the assurance and compliance needs of users of blockchain-based data storage systems.
FIG. 3 illustrates an exemplary process for deploying a distributed ledger validation tool according to examples of the disclosure. In the example of FIG. 3, the process 300 can begin at step 302 wherein the customer's (who will be using the validation system) blockchain use-case is analyzed. The use-case analysis performed at step 302 can include as an example, determining the type of blockchain that is being used by the customer, analyzing how the customer is using the block chain to effect transactions and what solutions the blockchain is meant to deliver to the customer.
Once a use-case analysis is completed at step 302, the process can move to step 304, wherein a risk framework analysis is applied to the customer blockchain. A risk framework is a tool that can be used by stakeholders or auditors to assess and define the assurance and compliance needs of a particular blockchain use-case. The framework can allow the user to step through a series of categories of risks (i.e., risks to an organization engendered by their use of blockchain) to determine what risks they wish to audit for, and to determine the extent to which those risks would harm the organization. The risk framework described above can be industry, use-case, and blockchain technology agnostic so that practitioners across all industries and sectors can use to address the risk assurance and compliance needs independent of the Blockchain technology variant and use case.
Practitioners can use the risk framework as a standard approach and framework to evaluate the current state of a Blockchain use case which can be inclusive of upstream and downstream (on-Blockchain and off-Blockchain) processes, technologies, and underlying data elements (people, processes, technologies) against 6 different risk categories, applicable domains, and 100+ sub-risk categories in order to address assurance and compliance needs (risks, control objectives, controls, testing objectives and procedures, and reporting parameters) of the following stakeholders simultaneously or exclusively. The risk categories, domains and sub-risk categories can be used exclusively or mutually exclusively to determine targeted and/or upstream and downstream impacts. These parameters can be used to customize and personalize an assurance or auditing software/tool to achieve required level of assurance and compliance as by-product of processed transactions.
In one or more examples, the risk framework can include such categories as: governance and oversight of the blockchain, cybersecurity issues with the blockchain, infrastructure risks, blockchain architecture risks, operational risks, and transactional risks. As part of using the risk framework, a user can (via user interface) go over each risk category and the sub-categories within each risk category and indicate which risks are pertinent to their organization (or that they wish to be analyzed), and also indicate the degree and scope of those risks using the risk framework.
Once a user has engaged the risk framework at step 304 to identify the risks they want analyzed during an audit, the process can move to step 306 wherein the user-preferences supplied to the risk framework can be converted in to one or more testing procedures to be performed during the real-time compliance testing of the customer's blockchain. As will be described in further detail below, the testing procedures can then be used by the validation/auditing software to in real-time audit the blockchain.
Once the results from the risk framework are converted to testing procedures at step 306, the process can move to step 308, wherein the real-time auditing tool is customized using the results gleaned from the risk framework. In one or more examples, customizing the auditing tool can include setting up one or more testing procedures that the tool will engage in during its operation, and also setting up the formatting of the reports that the tool will ultimately produce for review by the customer (described in further detail below).
Finally, once the tool has been customized per based on the assessment of the use-case established at step 302 and the application of the risk framework at step 304, the process can move to step 310 wherein the tool is deployed in the customer environment. As will be described in further detail below, deploying the tool can refer to the creation of a validation node that becomes part of the customer blockchain environment. The validation node can be a read only node that includes the software to run the test procedures discussed with respect to step 306 on blockchain transactions as they occur in real time in the customer environment.
In one or more embodiments, the validation system created by the process described with respect to FIG. 3, may utilize a permanent planning file that can contain the details and results of the risk framework application, that can then be used at step 306 to convert the risk framework results into testing procedures. In other embodiments, the permanent planning file can instead be directly created by a user without the need to engage in the risk framework analysis above.
In some embodiments, the above set of activities of the validating methodology may be executed systematically (e.g., via software, hardware, or a combination thereof) with manual input by the auditor or compliance practitioner. In one or more examples, the validating methodology described above with respect to steps 302 may be divided into three phases (e.g., planning, fieldwork, and reporting sprints). The three phases are described below.
Planning Phase: In some embodiments, steps 302, 304, and 306 of FIG. 3 may constitute the planning phase. During the planning phase, an assessment is performed to identify validating test procedures using blockchain validating criteria and risk framework. In order to provide a required level of assurance for any given blockchain use case, a standardized acceptance criterion is developed to capture inputs and outputs and set the right assurance threshold level based on stakeholders' requirements, as needed. A blockchain risk framework can be used to identify inputs and define outputs in order to create the required level of assurance. Based on the assessment results obtained from using the criteria and risk framework of step 304, validity test and reporting parameters are determined (at step 306).
Fieldwork Phase: In some embodiments, step 308 and 310 of FIG. 3 may constitute the fieldwork phase. During the fieldwork phase, the validating software may be customized with the test and reporting parameters determined in the planning phase. Once the customized software is deployed at step 310, transactional information can be captured based on the defined data parameters and passed through a rules engine (described in further detail below), which can host the validity test rules. Practitioner uses the validity software to execute real-time evidence gathering and testing across a data activities—level data population set on a real-time basis (or some other interval if preferred, e.g., bi-monthly or monthly).
As will be described in further detail below, the software can classify testing results as either an observation (visual or virtual alert) when the rule breaks/fails, or a no-observation if the transaction passes the test rule with no breaks/fails. A practitioner classifies an observation as either an exception/deviation noted, or no exception/deviation noted. Further, the practitioner raises exception(s)/deviation(s) noted per test procedure as an issue, including exception/deviation details, investigation results, issue summaries and details, impact rankings and details, and management action plan details.
Reporting Phase: In some embodiments, step 310 of FIG. 3 may constitute the reporting phase. Once the validity tests and other fieldwork activities (i.e., exceptions/deviations and issues) are complete, the deployed tool can produce an issue and interim audit report, including ratings and details at the process and subprocess levels to achieve continuous reporting and monitoring (or some other interval if preferred, e.g., bi-monthly or monthly. In some embodiments, after the interim reporting cycle for the quarter (or some other interval if preferred) is complete, practitioner produces and issues a quarterly audit report including ratings and opinions at the process and subprocess levels to the stakeholders.
The testing and reporting can provide the required assurance level information at the process and subprocess levels based on the applicable risks, controls, testing objectives, and reporting parameters across the entire population data set to address stakeholders' needs.
In some embodiments, the exception can be replaced with the deviation in the flow described above to address the process and functional needs of the stakeholders in compliance or non-compliance areas (outside of audit).
In some embodiments, the validating methodology provides a practitioner with an end-to-end standardized audit process and sets of activities that can be used to obtain real-time transparency around given business processes (i.e., non-blockchain and blockchain) and provide compliance and audit-type reporting automatically or manually. In some embodiments, the methodology enables the practitioner to execute set of audit and compliance activities by the computer in a continuous fashion, which can bring a significant increase in efficiency and effectiveness, achieving a higher/maximum level of confidence.
In some embodiments, the blockchain validation tool/system is designed and developed to provide real-time transaction-level assurance with immediate results across a full population data set, which can be used by stakeholders and end-users simultaneously or exclusively to address their assurance, audit, and/or compliance needs. Some examples of stakeholders would be such personnel as the head of innovation, head of corporate development, chief technology officer, head of business segment(s), and chief audit executive. Some examples of end-users would be internal users (e.g., operations (first line of defense), enterprise risk management (second line of defense), internal audit (third line of defense), and tax); and external users (e.g., legal and regulatory).
Some assumptions in performing real-time assurance may include that: (1) off-chain data (i.e., data not stored within the blockchain) exists and may be required for key assurance reporting; (2) ordering, integrity, and completeness of data activities in a blockchain can be critical to assurance; (3) while the integrity of blockchain data can be validated, third-party “off-chain” data is not immutable and subject to change; and (4) assurance is being conducted on the qualitative and quantitative data activities of the blockchain, rather than the technical blockchain implementation (consensus protocols, block formation rules, blockchain forks, etc.).
The blockchain validation system may include major five components: (1) customer environment 404, (2) integration unit 406, (3) data block service unit 408, (4) front-end service or reporting unit 410, and (5) interfaces 412. In addition, the system 400 may interface with third-party computing systems (as indicated by block 402) as well as the customer blockchain 404. The following sections discuss these architectural components of the blockchain validation system (which may be referred to as the blockchain assurance and validation solution, blockchain assurance and validating software, or blockchain assurance solution).
FIG. 4 illustrates an exemplary blockchain validation system according to examples of the disclosure. The following discussion with reference to FIG. 4 outlines a structure to establish a validation node capable of performing real-time assurance off third-party blockchains. The validation system consists of individual microservices performing discrete pieces of functionality, which, when holistically viewed, can enable real-time assurance and validation of data activities in data blocks of blockchains in a blockchain network. The blockchain network may have a plurality of blockchain nodes having blockchain-based data storage systems in each blockchain node as described above with respect to FIG. 1. In some embodiments, the blockchain network and the blockchain node of FIG. 4 may be represented by the network and nodes shown in FIG. 1. The discussion below provides insight into the primary responsibilities of each service as a new blockchain event or data block is added to a node in the blockchain network.
Some assumptions in performing real-time assurance may include that: (1) off-chain data (i.e., data not stored within the blockchain) exists and may be required for key assurance reporting; (2) ordering, integrity, and completeness of data activities in a blockchain can be critical to assurance; (3) while the integrity of blockchain data can be validated, third-party “off-chain” data is not immutable and subject to change; and (4) assurance is being conducted on the qualitative and quantitative data activities of the blockchain, rather than the technical blockchain implementation (consensus protocols, block formation rules, blockchain forks, etc.).
The blockchain validation system may include major five components: (1) customer environment 404, (2) integration unit 406, (3) data block service unit 408, (4) front-end service or reporting unit 410, and (5) interfaces 412. In addition, the system 400 may interface with third-party computing systems (as indicated by block 402) as well as the customer blockchain 404. The following sections discuss these architectural components of the blockchain validation system (which may be referred to as the blockchain assurance and validation solution, blockchain assurance and validating software, or blockchain assurance solution) with reference to FIG. 4.
To illustrate the functionality of the components contained within system 400, a description of the data flow in the architecture of FIG. 4 can be pertinent. The process of validating blockchain transaction can begin with the addition of a new data block from one of the blockchain nodes 418 residing in the customer's blockchain environment. When a node 418 attempts to introduce new data into the blockchain, that activity can be sent to chain listener 422. The chain listener can serve as the initial integration point between the blockchain assurance and validation tool, and the customer blockchain. The goals of the chain listener can be to emit transactional blockchain events occurring within the blockchain. In most cases, blockchains provide varying levels of “feed” data in instances where generic events or transactions are published to subscribers of its services; in these cases, the chain listener can leverage those existing services to provide events for downstream service consumers.
Events trigger the initial action that results in a transaction or data activity (or the addition of a block) within the blockchain. Events should trigger one or more transactions within the blockchain, indicating that some key information should be delivered across the blockchain network. These transactions will manifest as a simple key-value pair, as illustrated below:


	{

//on the blockchain

	_id: 3199444, //a unique identifier
	dateTime: 2103323223 //unix timestamp,

transaction; 2193298439843984381212211 //a transaction,

	sender: John Doe, //string
	receiver: Jane Doe, //string
	amount: 10 //integer
	}

In most industry use-cases, blockchains will not actually store transactional data. The use of a shared ledger implies the likely scenario in which sensitive-data transactions occur. Moreover, storage costs can escalate, and blockchains are not intended to store items such as images, documents, etc. As such, an event transaction may have a simple encrypted “hash,” which can contain a secret location that can be unencrypted by the asset owner. The same object described above can easily be represented as such:


{

// on the blockchain

_id: 3199444, //a unique identifier

dateTime: 2103323223 //unix timestamp,

	hash; 2193298439843984381212211 //an encrypted value that could
	represent anything

}

{

	// off the blockchain (such as in a relational database).
	_id:2193298439843984381212211,
	transaction; 2193298439843984381212211 //a transaction,

sender: John Doe, //string

receiver: Jane Doe, //string

amount: 10 //integer

}

A “push” feed (built within the blockchain protocol) is the ideal setup, because it properly segregates the responsibilities across the blockchain network and the assessment and validating software. As such, it is up to the blockchain to provide guarantees that ensure transactions are emitted while the chain listener is responsible for relaying those events into the validation system. If this service is ever stopped or interrupted, it should possess enough awareness and understanding to resume starting with its last acknowledged transaction. This ensures that transactions are not “duplicated” within the environment and that unnecessary work to “reprocess” blockchain transactions will not occur.
Thus, once the chain listener detects that a new transaction is occurring on the blockchain, it can tag the event and send them to event listener 442 by placing the events onto a queue 434. The event listener 442 may then pick up the new data block from queue 434 and perform a series of tasks with the new data block acquired from queue 434. In one or more examples, the event listener 442 may store a copy of the new data block by storing in event store 436. The event store 436 can be the principal “record of truth” that represents a historical copy of the blockchain from which all downstream systems derive their system state. Records that live as unstructured data, and events transacted from the blockchain listener, will live as JSON objects within this document store (e.g., MongoDB), and will live in its nearest representation to data on the blockchain. The primary goals of the event store can be twofold: (1) separating querying and data, extraction responsibilities from the validation node (to avoid directly querying the blockchain for events); and (2) creating a consistent storage abstraction that can be leveraged regardless of the blockchain platform.
The event store can also enable additional capabilities such as data “snapshots,” where events or transactions can be “replayed” as they occur. The event log provides a strong audit capability (e.g., accounting transactions are an event source for account balances) where historic states can be recreated by replaying past events.
Simultaneously to storing the event at event store 436, the event listener 442 can transmit the new data block to data enricher 424 by placing it into a queue 432. The data enricher 424 can take the data block stored at queue 432 and request information from external data sources (e.g., from a customer or third party) through the off-chain API 426 that collects third-party data stored at 414, and off-chain data stored at 416. External data sources can be centrally managed through the use of an off-chain API 426 that can federate requests to one or many external data sources such as third party data 414 or off-chain data 416. External data sources are centrally managed through the off-chain API 426, which federates requests to one or many external data sources. Off-chain data (sometimes referred to as oracles) provide, contextual information about blockchain data, including real-time data elements (e.g., stock prices), personally identifiable or sensitive information (e.g., names or addresses), or extraneous metadata, which could bloat the size of the blockchain ledger. Through the creation of its own independent service, the application reduces the tight coupling between internal and external application logic, and limits exposure to third-party systems.
Customer environment 404 which can store off-chain data 416, as well as third party data coming from data store 414 can describe the spectrum of tasks occurring within third-party networks and the original inception of the transaction, data activities, or data block onto the blockchain-based data storage system. While upstream (i.e., actions prior to hitting the blockchain) activities should be considered “out of scope” of the tool 400—need for assurance can require that examination occurs as close to the original “source of truth” as possible—it can therefore be essential for critical data elements or keys to exist within the blockchain, or else they will not be captured by the downstream processes. Careful design of blockchain metadata is needed to enable the ability for assurance and validation. Thus, customer environment 404 can collect and store various “off-chain” data at data store 416.
As an example of off-chain data, if a distributed ledger is storing emails being sent back and forth from the customer, the names associated with each email address could be an example of “off-chain data” that could be used to help validate and audit the blockchain itself. Thus, the type of data that while not needed for action block creation itself, may be needed to validate transactions occurring in real-time can be stored at data store 416. Off-chain storage contains data that is not readily available for public consumption. Off-chain storage may reference anything from trade data to vendor/sales information, or anything that provides context to the transactions inscribed on the block.
While blockchain data is historic and immutable, off-chain data is not immutable or immune to tampering. This makes logical sense: off-chain data will likely be sensitive, business-contextual data and will often be used by multiple consumers within an organization. The duplication of data across off-chain and on-chain data which poses consistency issues and the two are in-sync. It is possible that records reflected within the blockchain are not represented off-chain. Downstream processes will need to reflect this known hazard when they are working with off-chain data by properly rebuilding or reconstructing records that require updates to ensure the audit solution accurately reflects the historic state.
Once the data enricher 424 adds in the off-chain data, it can then transmit the augmented even to rules engine 428 via queue 430. Customer-specific business assurance rules can applied to the data block in the rules engine 424. Rules can be highly specific to the business and industry concerned and be customized according to each customer as described above with respect to the risk framework. Rules can the cornerstone of the validation solution, providing the basis of when/why transactions violate specified conditions.
The rules engine 428 can be implemented as a worker with a specified set of instructions on how to apply rules against transactions. Because the user interface also relies on the awareness and knowledge of rules, the rules engine can retrieve the latest inventory of rules from a shared database (not pictured). While this extra network request may seem unnecessary, it also can enable user-features such as the dynamic toggling of rules, the addition/subtraction of rules without hard resets, etc.
Two categories of rules may be applied to transactions or data activities in the blockchain: streaming rules that assess against individual transactions, and batch rules that assess against an aggregate of transactions.
Streaming Rules: Incoming transactions can be evaluated against a set of one or many business rules that can assess validity across a variety of dimensions (e.g., completeness of a transaction, blacklisting of specific values, application of transaction logic such as input=output, etc.).
Batch Rules: Incoming transactions that possess some relationship to historical or past events can leverage the event store to identify patterns that may violate assurance rules (e.g., aging transactions, number of transactions from an account, etc.).
These rules are generators of “observations” within the solution. Observations indicate the violation of a pre-defined guideline set by business or assurance rules, which Users of the system will evaluate within the web interface. As will be described in detail below, the observations can be collected and presented to a user, who can then review each observation and determine whether the observation warrants further scrutiny.
Once the rules engine 428 applies the one or more rules to the data block, the results of the tests performed by the rules engine can be sent to reporting database 444. Reporting database can store the results of the application of the rules to the data block.
The reporting DB is the final staging area where business-oriented data structures can be queried and analyzed. Any blockchain transaction saved within the event store will create one or many transactions within the reporting DB; this will allow a variety of views to be “staged” and immediately ready for analytics, assurance reports, etc.
In order to create this reporting state for user interfaces, any off-chain data must be already “enriched” and co-located with other blockchain events. The integration of off-chain and on-chain data will require a high degree of collaboration and integration between the third party and the tool.
Reliability and uptime of external systems can be unpredictable, and the present invention anticipates “offline” scenarios where external systems are unavailable. Moreover, the current state of the reporting DB can be off-sync with its original source of truth if records have been updated within the host system.
To resolve these issues, the architecture should incorporate several precautionary measures to ensure the reporting DB is in an accurate representation of its source of truth. In the “offline” scenario, worker jobs should fail, persist, and retry to ensure transactions are not lost. Additionally, periodic background validation jobs should have the ability to check the accuracy and updates of records. This integration has the potential to be complex, depending on the auditability and traceability of third-party systems.
The results stored in reporting database 444 can be sent to user interface 412 for further evaluation via reporting API 448. The reporting platform will be the sole interface through which users interact and communicate with blockchain data. A separate “reporting API” provides external users with access into data that has already been relayed, saved, and transformed into contextual and relevant pieces of information. This information is ready to be consumed by the web interface, which enables risk assurance professionals to make decisions according to real-time events on the blockchain.
The user interface presents the results of the test procedures to the rules engine. The user interface may be a web page, a web dashboard, a mobile device, or any other device that is configured to display or output the validation report.
Referring back to FIG. 3, at step 304 a risk framework can be used to generate one or more tests. Those tests can then be transmitted to rules engine 428 in the system described in FIG. 4 to perform real-time and continuous validation of a blockchain system. The risk framework can allow for a user to specify the risks they wish to monitor for during their testing and the level of assurance they are seeking, and those inputs can be converted into a plurality tests that are run during the operation of the blockchain. Thus, while all users of the validation tool can be presented with a common risk framework, the output of the risk framework can be specific to each individual user/organization to ultimately generate a unique validation tool that addresses the specific needs of the organization.
The discussion below can illustrate how the risk framework described above can fit in with an overall approach to risk management for validating a blockchain system.
In some embodiments, determining the acceptance criteria (may be referred to as assurance threshold formula) may include the five steps discussed below.
1—Purpose (P1)—Gain an understanding of the blockchain use case, business purpose, and the resultant effect on the risks and control objectives.
2—Process (P2)—Assess on and off blockchain processes and technologies to understand continuous assurance methodology affects, up and downstream, on audit expectations and the entire process risk profile.
3—Risks (Rs)—Assess the blockchain architecture variant and identify applicable control objectives using the blockchain risk framework.
4—Stakeholder (Sr)—Identify assurance related stakeholders, determine and inventory their expectations and needs for reporting purposes.
5—Assurance Threshold Formula (ATx)—Total number of test procedures required to achieve the required level of assurance. The test procedures can be coded into the rule engine of the audit software/tool for automated testing and transaction level assurance.
Based on the results obtained from these four activities in combination of the blockchain risk framework, the following Assurance Threshold Formula (ATx) is determined:
P1+P2+Rs+Sr=ATx
The solution sum of Y (Continuous Audit) must always be equal or greater than ATx in order to create the necessary level of assurance. Therefore Y ATx.
As shown above, the risk framework (step 3) can work to provide a required level of assurance to a customer that their blockchain system is operating with minimal risk.
In some embodiments, the blockchain risk evaluation system or risk framework may assess the current state of a blockchain use case against different risk categories (e.g., six or more different risk categories) and across sub-categories (e.g., 100 or more different sub-categories) in order to address assurance and compliance needs of stakeholders. This assessment may be performed by a risk evaluation system that is industry, use case and Blockchain platform agnostic. In some embodiments, the results of these assessments provide the necessary information to identify applicable risks, control objectives, testing reporting and reporting parameters that are used to customize our the continuous validating software.
The blockchain risk framework is a component of the blockchain continuous validating solution. Due to availability and use of several variants of blockchain technology for use cases and lack of a standard approach or risk frameworks that can be used to obtain required level of transparency for a given blockchain use to meet compliance, assurance, and audit requirements, an approach has been designed and the supporting framework is developed that is industry, use case and blockchain technology variant agnostic so that practitioners across all industries and sectors can use to address the risk assurance and compliance needs independent of the blockchain technology variant and use case.
Practitioners can use blockchain risk evaluation system as a standard approach and framework to evaluate the current state of a Blockchain use case which can be inclusive of upstream and downstream (on-Blockchain and off-Blockchain) processes, technologies, and underlying data elements (people, processes, technologies) against 6 different risk categories, applicable domains, and 100+ sub-risk categories in order to address assurance and compliance needs (risks, control objectives, controls, testing objectives and procedures, and reporting parameters) of the following stakeholders simultaneously or exclusively. The risk categories, domains and sub-risk categories can be used exclusively or mutually exclusively to determine targeted and/or upstream and downstream impacts. These parameters can be used to customize and personalize an assurance or validating software/tool to achieve required level of assurance and compliance as by-product of processed transactions.
Some examples of stakeholders provided below:

- Chief Executive Officer
- Chief Financial Officer
- Chief Technology Officer
- Chief Information Security Officer
- Chief Audit Executive (3rd Line of defense)
- Head of Enterprise Risk Management (2nd line of defense)
- Head of Operations (1st line of defense)
- Head of Innovation
- Head of Corporate Development
- Head of Compliance and legal
- Head of Tax
- External Regulators
- Head of Business Segment(s)

Risk Categories:
In Some Embodiments, Some Examples of Risk Categories and their relevant domains are provided in Table 1.

TABLE 1

Risk Category	Domain

Governance and	Business Objectives
Oversight	Program Sponsorship
	Leadership Commitment
	MIS and Metrics
	Program Management
	Operational and Capital Expenditure Oversight
	Project Management
	Third-party Risk
Cyber Security	Cloud Security
	Data Security
	Data Privacy
	Penetration Testing
	Programming Security
	Network Security
	Patch and vulnerability
	Threat detection
	Threat response
Infrastructure Layer	Servers and Databases Configuration
	ITGCs
	Business Continuity and Disaster Recovery
	IT Asset Management
Architecture Layer	Blockchain Platform & Protocol Configuration
	Hardware Security Modules
	Signature Management
	Cryptography
	Scalability
	Availability
Operational Layer	Permissioned network management
	Participant Onboarding and Off-boarding
	Application layer
	Blockchain consensus program management
	Integration with off-Blockchain systems and
	processes
Transactional Layer	Smart Contracts
	Digital Assets
	Digital Currency
	Clearing and settlement
	Business Use Case Transactions

The sub-risk categories, control and testing objectives, test procedures and request lists for each for the above risk categories and domains of Table 1 are provided below. When engaging with the risk framework, a user using a computer/laptop or some other computing device, can be guided through each risk category and specify parameters relating to the category. In one or more examples, the user can specify if a particular risk is to be classified as low, medium, or high. In one or more examples, the categories, low, medium, high, can change for one risk, from one blockchain system to another. As an example, because there may be other surrounding controls in place or there may be some compensating controls in place, a particular risk may be categorized as low. Alternatively another in another blockchain environment, a user may assess that risk to be high because the system doesn't have certain compensating controls in place or certain processes or technology or checks and balances in place. In such a system the risk maybe categorized as high. Thus classifying a risk as low, medium, high, can mean that there's a possibility that this can fall into either of these three categories, depending on the use case and depending on the environment, that is being examined.
In some embodiments, governance and oversight risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain portfolio and program management, governance, and oversight. Focus areas for this category includes blockchain strategy, research and development, investment, business, operations, product and use case solution development activities.
The sub-risk categories, control and testing objectives, test procedures and request lists for Governance and Oversight risk category are provided below in Tables 2-4. Table 2, is an exemplary sub-risk category table for the governance and oversight risk category. The table below can be presented to a user accessing the risk framework from a computing device configured to receive inputs from a user. The table below can include a risk category indicator that specifies the category of risk as defined above. Each of the Risk Categories cover Blockchain including upstream and downstream processes, technologies stacks, and people and associated risk profiles.
The table below can include a domain column can identify the areas relevant to the blockchain that is covered by each risk category. In one or more examples, the table below can include a risk classification column that identifies the applicable processes and technologies within each domain, where the risk is present. In one or more examples, the table below can also include a risk number that simply provides a method for identifying the risk in numerical form. In one or more examples, the table below can also include a risk description that describes the risk applicable to/associated with the processes and technologies within each domain. In one or more examples, and as described above, the table can also include a risk level rating (low, medium, high) as described above.
When the user is presented with the framework, they can initially review each risk category, and specify whether such a risk is a low, medium, or high concern. Presented below is an example risk table for the government and oversight risk category.

TABLE 2

					Risk Level (L,
					M, H)
		Risk	Risk		(As
Risk Category	Domain	Classification	Number	Risk Description	applicable)

Governance	Business	Strategic,	GO-BO1	At the senior management level,	L, M, H
and Oversight	Objectives	Operational,		business objectives and justification is
		Financial,		not clearly defined leading to failure
		Compliance,		of program and misalignment with
		Legal, or		strategy and overarching governance
		Reputational		framework.
Governance	Business	Strategic,	GO-BO2	The Blockchain Program is	L, M, H
and Oversight	Objectives	Operational,		implemented in silos without a formal
		Financial,		oversight committee resulting in
		Compliance,		inefficient utilization and duplication
		Legal, or		of efforts.
		Reputational
Governance	Business	Strategic,	GO-BO3	Unapproved or miscommunicated	L, M, H
and Oversight	Objectives	Operational,		scope can lead to failure of program or
		Financial,		poor utilization of program resources.
		Compliance,
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PS1	Lack of involvement from Senior	L, M, H
and Oversight	Sponsorship	Operational,		Management can lead to low
		Financial,		organizational awareness and failure
		Compliance,		of the Blockchain program.
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM1	Failure to define and monitor Key	L, M, H
and Oversight	Management	Operational,		Performance Indicators (KPIs) may
		Financial,		lead to failure of the program.
		Compliance,
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM2	Failure to formalize methodology for	L, M, H
and Oversight	Management	Operational,		inventorying, analyzing, prioritizing
		Financial,		and selecting eligible the Blockchain
		Compliance,		use cases may lead to failure of the
		Legal, or		program.
		Reputational
Governance	Program	Strategic,	GO-PM3	Failure to define and effectively	L, M, H
and Oversight	Management	Operational,		monitor project progress may lead to
		Financial,		failure of the program.
		Compliance,
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM4	Failure to assess the level of change	L, M, H
and Oversight	Management	Operational,		readiness for the organization when
		Financial,		implementing Blockchain may lead to
		Compliance,		failure of program.
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM5	Failure to define the go-live criteria	L, M, H
and Oversight	Management	Operational,		within the program objectives may
		Financial,		lead to failure of the program.
		Compliance,
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM6	Failure to identify proper resources to	L, M, H
and Oversight	Management	Operational,		fulfill roles with the Blockchain
		Financial,		program and lack of learning and
		Compliance,		development to ensure that employees
		Legal, or		skills are in line with the needs of the
		Reputational		Blockchain program leads to
				excessive turnover and inadequate
				resources.
Governance	Program	Strategic,	GO-PM7	Failure to consider changes in the	L, M, H
and Oversight	Management	Operational,		business process due to Blockchain
		Financial,		technology could lead to loss of
		Compliance,		institutional knowledge.
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM8	Lack of acceptance from users and	L, M, H
and Oversight	Management	Operational,		employees of the Blockchain program
		Financial,		could lead to failure of the program.
		Compliance,
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM9	Lack of acceptance from users and	L, M, H
and Oversight	Management	Operational,		employees of the Blockchain program
		Financial,		could lead to failure of the program.
		Compliance,
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM10	Inadequate processes to setup	L, M, H
and Oversight	Management	Operational,		Blockchain vendor software could
		Financial,		lead to increased risks to security
		Compliance,		requirements.
		Legal, or
		Reputational
Governance	Program	Strategic,	GO-PM11	Inadequate assessment of hardware,	L, M, H
and Oversight	Management	Operational,		applications, software and software
		Financial,		components may leave information
		Compliance,		systems vulnerable and unable to
		Legal, or		fulfill business objectives.
		Reputational
Governance	Program	Strategic,	GO-PM12	Lack of a standard process to	L, M, H
and Oversight	Management	Operational,		document functional specifications for
		Financial,		each business process can lead to
		Compliance,		incomplete or inaccurate
		Legal, or		documentation.
		Reputational
Governance	Program	Strategic,	GO-PM13	Failure to define and develop a clear	L, M, H
and Oversight	Management	Operational,		benefits strategy could lead to failure
		Financial,		of the Blockchain program.
		Compliance,
		Legal, or
		Reputational
Governance	Project	Strategic,	GO-PM14	Failure to assign appropriate resources	L, M, H
and Oversight	Management	Operational,		to aid in the design of application
		Financial,		security and controls may result in
		Compliance,		increased risks to the business and
		Legal, or		insufficient controls around the
		Reputational		business processes.
Governance	Project	Strategic,	GO-PM15	Employees who are not appropriately	L, M, H
and Oversight	Management	Operational,		trained may result in an increased risk
		Financial,		of bypassed or forgotten
		Compliance,		considerations essential to the
		Legal, or		Blockchain Program.
		Reputational
Governance	Project	Strategic,	GO-PM16	Failure to allocate appropriate	L, M, H
and Oversight	Management	Operational,		representation and resources for the
		Financial,		duration of the program, may lead to
		Compliance,		the misuse of organizational funds and
		Legal, or		unintended risks to business
		Reputational		objectives.
Governance	Project	Strategic,	GO-PM17	Lack of monitoring activities in place	L, M, H
and Oversight	Management	Operational,		could lead to inaccurate and
		Financial,		incomplete transactions processed
		Compliance,		within the Blockchain application.
		Legal, or
		Reputational
Governance	Leadership	Strategic,	GO-LC1	Poor stakeholders and leadership	L, M, H
and Oversight	Commitment	Operational,		commitment can lead to a lack of
		Financial,		unity on program goals, objectives
		Compliance,		and performance.
		Legal, or
		Reputational
Governance	MIS and Metrics	Strategic,	GO-MM1	Failure to allocate appropriate	L, M, H
and Oversight		Operational,		resources, while considering business
		Financial,		requirements, may lead to the misuse
		Compliance,		of organizational funds and
		Legal, or		unintended risks to business
		Reputational		objectives.
Governance	MIS and Metrics	Strategic,	GO-MM2	Inadequate controls to monitor the	L, M, H
and Oversight		Operational,		capacity, availability, and
		Financial,		functionality of the application may
		Compliance,		lead to interruption and/or failure to
		Legal, or		key applications.
		Reputational
Governance	Operational and	Strategic,	GO-OC1	Failure to allocate appropriate	L, M, H
and Oversight	Capital	Operational,		resources, while considering business
	Expenditure	Financial,		requirements, may lead to the misuse
	Oversight	Compliance,		of organizational funds and
		Legal, or		unintended risks to business
		Reputational		objectives.
Governance	Operational and	Strategic,	GO-OC2	Failure to allocate appropriate	L, M, H
and Oversight	Capital	Operational,		resources, while considering business
	Expenditure	Financial,		requirements, may lead to the misuse
	Oversight	Compliance,		of organizational funds and
		Legal, or		unintended risks to business
		Reputational		objectives.
Governance	Operational and	Strategic,	GO-OC3	Failure to allocate appropriate	L, M, H
and Oversight	Capital	Operational,		resources, while considering business
	Expenditure	Financial,		requirements, may lead to the misuse
	Oversight	Compliance,		of organizational funds and
		Legal, or		unintended risks to business
		Reputational		objectives.
Governance	Operational and	Strategic,	GO-OC4	Inadequate controls to govern and	L, M, H
and Oversight	Capital	Operational,		address security risks in a project may
	Expenditure	Financial,		lead to loss of sensitive data.
	Oversight	Compliance,
		Legal, or
		Reputational
Governance	Smart Contracts	Strategic,	GO-SC1	Blockchain software use cases are not	L, M, H
and Oversight		Operational,		consistent with participants' business
		Financial,		or industry-specific requirements;
		Compliance,		smart contracts cannot be effectively
		Legal, or		leveraged for normal operations
		Reputational
Governance	Smart Contracts	Strategic,	GO-SC2	Blockchain implementation lacks a	L, M, H
and Oversight		Operational,		coherent governance model for
		Financial,		development, execution, and oversight
		Compliance,
		Legal, or
		Reputational
Governance	Smart Contracts	Strategic,	GO-SC3	Lack of IP safeguards compromise the	L, M, H
and Oversight		Operational,		organization's DLT innovations
		Financial,
		Compliance,
		Legal, or
		Reputational

After categorizing the risks as described above, the framework can then present the user with series of control/test objectives (with corresponding descriptions) which the user can review and determine whether such controls/test objectives should be considered in-scope to the audit or out of scope to the audit. An exemplary control/test objective table is provided below for the governance and oversight risk category.

TABLE 3

				In-scope/Out-
				of-Scope
Risk				(TBD - As per
Category	Domain	Control/Test Objective	Control Description	engagement)

Governance	Business	At the senior management level,	The Blockchain Program Charter is	In-scope
and Oversight	Objectives	business justification and	created and includes specific details of
		objectives for the Blockchain	goals and business objectives of the
		Program is documented and	overall Blockchain Program. The
		aligns with business strategy.	Blockchain steering committee reviews
		The Blockchain Program is	and approves The Blockchain Program
		considered in the overarching	Charter to ensure it is in alignment with
		governance framework with	the firm's organizational and
		alignment to risk, compliance	governance strategies.
		and IT/data frameworks.
Governance	Business	The Blockchain Program is	A Blockchain steering committee,	In-scope
and Oversight	Objectives	appropriately prioritized against	which includes executive leadership
		other initiatives within the	and senior members of the business,
		organization.	risk, compliance and the Blockchain
			program management, meets on a
			quarterly basis to conduct business
			performance reviews of how the
			Blockchain Program aligns with
			business strategy.
Governance	Business	The Blockchain program project	The scope of the Blockchain program is	In-scope
and Oversight	Objectives	plan has been defined	outlined in the Blockchain project
		addressing each phase of the	plan/roadmap. The project plan is
		Blockchain program project and	reviewed and approved by the steering
		is consistent with the scope and	committee to ensure the plan is in
		objectives defined within the	alignment with the Blockchain Program
		program charter. The scope of	Charter.
		the Blockchain Program has
		been approved and
		communicated by all
		participants.
Governance	Program	Senior Management is actively	The Blockchain Program Charter is	In-scope
and Oversight	Sponsorship	involved in creating	created and includes specific details of
		organizational awareness,	the communication strategy to the
		championing the Blockchain	broader organization. The Blockchain
		program.	steering committee reviewed and
			approved The Blockchain Program
			Charter.
Governance	Program	Key Performance Indicators	Key Performance Indicators (KPIs) are	In-scope
and Oversight	Management	(KPIs), specific to the	established to monitor the Blockchain
		Blockchain use case, to monitor	program performance.
		program performance have been
		developed.
Governance	Program	Formalized methodology for	The Blockchain program policies and	In-scope
and Oversight	Management	inventorying, analyzing,	procedures, which includes
		prioritizing and selecting	methodology for inventorying,
		eligible the Blockchain use	analyzing, prioritizing and selecting
		cases exists. This method is	eligible the Blockchain use cases, are
		formally documented to ensure	reviewed and approved on a periodic
		consistently across business	basis.
		units that may potentially utilize
		the technology.
Governance	Program	The Blockchain program project	The Blockchain Program steering	In-scope
and Oversight	Management	plan has been defined	committee reviewed and approved The
		addressing every phase of the	Blockchain program project plan. The
		Blockchain program project and	Blockchain program management
		is consistent with the scope and	monitors individual project work plans
		objectives defined within the	to measure progress against The
		program charter. Individual	Blockchain project plan.
		project work plans are well
		defined and effectively
		monitored for project progress;
		an integrated master plan that
		provides a comprehensive view
		of work effort and dependencies
		across all project teams has
		been defined.
Governance	Program	Affected stakeholders are	The processes selected for Blockchain	In-scope
and Oversight	Management	actively involved in the	implementation are evaluated on a
		planning process and the	quarterly basis by the Blockchain
		Blockchain Program team has	program management team to ensure
		formally assessed the level of	the Blockchain technology is being
		change readiness for the	optimized and decisions adhere to the
		organization and its business	Blockchain selection criteria outlined in
		units, stakeholders, and	the Blockchain program policies and
		customers.	procedures. The results of this
			evaluation are reported to the
			Blockchain steering committee.
Governance	Program	Formal go-live criteria for each	Formal policies and procedures have	In-scope
and Oversight	Management	application/use case is	been established and documented to
		adequately linked back to the	outline the methodology for the
		program scope and objectives.	Blockchain configuration and
			maintenance, including decision
			making criteria to go live being
			formally documented. Policies and
			procedures are reviewed and approved
			on a periodic basis.
Governance	Program	Management has updated	The Blockchain program policies and	In-scope
and Oversight	Management	staffing and hiring practices to	procedures, which includes details of
		ensure the right people within	the formal the Blockchain organization
		the organization are identified	structure, staffing and training
		and assigned as the Blockchain	requirements are reviewed and
		program resources. Learning	approved on a periodic basis.
		and development personnel
		have been engagement to ensure
		training program has been
		instituted to train the
		Blockchain Program staff.
Governance	Program	There has been adequate	Periodically, management performs a	In-scope
and Oversight	Management	considerations for loss of	risk assessment of the Blockchain
		institutional knowledge as the	technology and evaluates the risk
		Blockchain technology alters/	associated with loss of institutional
		eliminates steps in business	knowledge.
		processes.
Governance	Program	There is adequate	Management has considered the impact	In-scope
and Oversight	Management	considerations for the	that the Blockchain program will have
		organizations resistance to	on resources and has designed a formal
		change and appropriate people	people and change process to mitigate
		and change management	possible disruptions and resistance
		processes are put into place to	across the organization.
		clearly articulate the future state
		and address possible disruption
		discomfort with a new
		technologically sophisticated
		process that will result in large
		decreases in manpower
		requirements.
Governance	Program	A formal process to address	The Blockchain Program Charter	In-scope
and Oversight	Management	organizational changes,	outlines a formal process to address
		including the ability to perform	organizational changes. The
		tasks in case of the Blockchain	organizational change process is
		failure.	analyzed and evaluated on a monthly
			basis by the Blockchain program
			management team. The results of this
			evaluation are reported to The
			Blockchain steering committee.
Governance	Program	The setup of the Blockchain	The Blockchain vendor software for	In-scope
and Oversight	Management	vendor software includes	initial integration into the firm's
		consideration of new security	environment follows a well-defined
		requirements to maintain	integration plan and is monitored by the
		confidentiality, integrity, and	Blockchain program management.
		availability have been
		considered.
Governance	Program	Hardware (including	Impact of software integration on the	In-scope
and Oversight	Management	configurations, locations,	firm's existing hardware configurations,
		capacity/capacity utilization,	software and applications is
		and age and data requirements),	documented and evaluated. The results
		applications, software and	of this evaluation are reported to the
		software components impacted	Blockchain Program steering
		by the Blockchain integration	committee.
		have been identified, evaluated
		and reported on.
Governance	Program	The process to create functional	The Blockchain program policies and	In-scope
and Oversight	Management	specifications for each new	procedures, which includes the process
		Blockchain business process	to create functional specifications for
		follows a standard process	each new the Blockchain business
		documented in the Blockchain	process, are reviewed and approved on
		Program policies and	a periodic or as needed basis.
		procedures.
Governance	Program	A benefits realization strategy	The Blockchain Program Charter is	In-scope
and Oversight	Management	has been developed and	created and includes the Blockchain
		approved.	Benefits Management process. The
			Blockchain Program steering
			committee reviews and approves the
			Blockchain Program Charter to ensure
			it is in alignment with the firm's
			organizational and governance
			strategies.
Governance	Project	Appropriate members of the	The Blockchain program management	In-scope
and Oversight	Management	business, the Blockchain	team includes members from risk and
		program team, risk, and	compliance responsible for designing
		compliance are actively	and implementing key controls being
		involved in design of	executed by the Blockchain
		application security and	technology. The functional
		controls.	specifications for each new the
			Blockchain business process are
			reviewed by the Blockchain Program
			risk & compliance team member to
			assure the appropriateness of the design
			and operating effectiveness of controls
			the Blockchain is executing.
Governance	Project	Individuals are properly trained	The Blockchain Program configuration	In-scope
and Oversight	Management	to configure the Blockchain	analysts are required to complete
		technology.	training prior to being involved with
			functional or technical Blockchain
			design. On an ongoing basis,
			individuals involved in the Blockchain
			program receive updated education to
			keep current with emerging technology
			issues.
Governance	Project	There is adequate commitment	The Blockchain policies and	In-scope
and Oversight	Management	to provide appropriate	procedures are defined and include a
		representation and resources for	description of key Blockchain program
		the duration of the Blockchain	management positions, responsibilities
		program.	and overall organization structure for
			governance.
Governance	Project	Post implementation, there are	Post implementation reviews are	In-scope
and Oversight	Management	monitoring activities in place to	performed by the required business
		monitor the completeness and	and/or technology management or
		accuracy of processing for the	designee to test the completeness and
		Blockchain transactions.	accuracy of processing for the
			Blockchain transactions.
Governance	Leadership	The Blockchain program	Leadership discusses and engages with	In-scope
and Oversight	Commitment	stakeholders have been	the business to determine Blockchain
		adequately engaged and	goals and objectives. The Blockchain
		understand the Blockchain	Program Charter is created and
		program goals and objectives.	includes specific details of goals and
			business objectives of the overall the
			Blockchain Program. The Blockchain
			steering committee reviews and
			approves The Blockchain Program
			Charter to ensure it is in alignment with
			the firm's organizational and
			governance strategies.
Governance	MIS and	There is a formal process for	The Blockchain project plan/roadmap	In-scope
and Oversight	Metrics	monitoring the Blockchain	details the financial needs of each
		program project performance	individual project work stream. The
		and details of performance is	Blockchain program management has a
		communicated to appropriate	formal process to monitor project costs
		stakeholders.	as it relates to project progress,
			milestones, and deliverables, as well as
			specifics to measure KPI, ROI per
			process and overall ROI. Monthly, the
			project costs are reported back to the
			Blockchain steering committee.
Governance	MIS and	There is sufficient oversight	Daily, the Blockchain Operational	In-scope
and Oversight	Metrics	over the application by to	management reviews capacity,
		ensure the Blockchain is logged,	availability and performance metrics of
		functioning, and workloads,	the Blockchain in production.
		availability and capacity are	Deviations from standard metrics are
		being efficiently and effectively	noted, researched and resolved.
		balanced.	Monthly these metrics are report to the
			Blockchain Program steering
			committee.
Governance	Operational and	Financial needs of the program	The Blockchain Program Charter is	In-scope
and Oversight	Capital	have been reviewed and	created and includes the financial needs
	Expenditure	approved by senior management	of the Blockchain program. The
	Oversight	and assessment of those needs	Blockchain steering committee reviews
		are reassessed on an ongoing	and approves the Blockchain Program
		basis.	Charter. Additionally, the Blockchain
			project plan/roadmap details the
			financial needs of each individual
			project work stream.
Governance	Operational and	The organization allocates	The organization establishes a plan for	In-scope
and Oversight	Capital	appropriate resources to	the allocation of appropriate resources
	Expenditure	information security and risk	to projects and programs based on
	Oversight	management.	assessing organizational, operational,
			and strategic considerations.
Governance	Operational and	The organization allocates	Resources (human, technology,	In-scope
and Oversight	Capital	appropriate resources to	finance) required to achieve security
	Expenditure	information security and risk	objectives are allocated for the
	Oversight	management.	establishment, implementation,
			maintenance and continual
			improvement of the information
			security management system.
Governance	Operational and	Implement security controls in	Information security is addressed in	In-scope
and Oversight	Capital	projects.	project management, regardless of the
	Expenditure		type of the project.
	Oversight

Finally once the user has identified the risks (including their particular levels), and has determine which test objectives are in-scope and out-of-scope to the validation, the risk framework can then provide the user with the applicable tests that will be applied to the user's blockchain validation system. The table below can be created based on the user's inputs to the reference framework described above. The table below can indicate the test procedures to be performed that determine the design or operating effectiveness of a control specified in table 3. The table below can also specify the test type which can be inquiry, inspection and observation, as well as attribute or substantive type of testing using a manual or automated approach. Finally, the table below can also present the user with a request list that can show the user requested items to be gathered to provide supporting information such as documentation or evidence including data parameters to execute test procedures in order to obtain the specified level of assurance and confidence surrounding the process and technology.

TABLE 4

			Test Type
			(TBD - As
Risk			per
Category	Domain	Test Procedure (#)	engagement)	Request List (#)

Governance	Business		1. Verify the Blockchain Program	Inquiry,	1. Blockchain Program Charter
and	Objectives	Charter has been created and review	Inspection,	2. Meeting minutes from the Steering
Oversight		the overall goals and business	and/or	committee meeting where the Blockchain
		objectives.	observation	Program charter was reviewed.
		2. Inspect the Blockchain Program
		Charter to ensure the Steering
		committee has reviewed and
		approved it.
Governance	Business		1. Inquire with Blockchain steering	Inquiry,	1. Meeting minutes from the Steering
and	Objectives	committee members to determine	Inspection,	committee where business performance
Oversight		criteria for business reviews to	and/or	reviews of how the Blockchain Program
		assess the Blockchain program's	observation	aligns with business strategy are discussed
		alignment with business strategy		and reviewed.
		2. Inspect Quarterly meeting
		minutes to confirm that business
		performance reviews were
		conducted by the established
		criteria.
Governance	Business		1. Inspect the Blockchain project	Inquiry,	1. Blockchain project plan/roadmap
and	Objectives	plan/roadmap to confirm that scope	Inspection,	2. Blockchain Program Charter
Oversight		of program is outlined.	and/or	3. Meeting minutes from the Steering
		2. Inquire with Steering committee	observation	committee where project plan/roadmap was
		to ensure that plan was reviewed		reviewed and approved.
		and approved, as evidence that plan
		is in line with Blockchain Program
		Charter.
Governance	Program		1. Inquire and inspect the	Inquiry,	1. Blockchain Program Charter
and	Sponsorship	Blockchain Program Charter to	Inspection,	2. Evidence that the Blockchain Program
Oversight		confirm details regarding the	and/or	Charter was reviewed and approved.
		communication strategy to the	observation
		broader organization.
		2. Inspect that the Blockchain
		Program Charter has been reviewed
		and approved.
Governance	Program		1. Inquire with Blockchain	Inquiry,	1. Blockchain Program KPIs
and	Management	Operational Management to ensure	Inspection,
Oversight		Key Performance Indicators (KPIs)	and/or
		have been established and	observation
		monitored.
		2. Inspect evidence to determine
		KPIs are monitored periodically.
Governance	Program		1. Inquire with management on	Inquiry,	1. Blockchain program policies and
and	Management	methodology for inventorying,	Inspection,	procedures.
Oversight		analyzing, prioritizing and selecting	and/or	2. Evidence of review and approval on a
		eligible the Blockchain use cases.	observation	periodic basis of the Blockchain program
		2. Obtain and inspect Blockchain		policies and procedures.
		program policies and procedures
		and confirm that methodology for
		inventorying, analyzing, prioritizing
		and selecting eligible the
		Blockchain use cases is included.
		3. Inquire with management and
		inspect that program policies and
		procedures are reviewed and
		approved on a periodic basis.
Governance	Program		1. Inquire with Steering committee	Inquiry,	1. Blockchain Program Charter
and	Management	to ensure that plan was reviewed	Inspection,	2. Meeting minutes from the Steering
Oversight		and approved, as evidence that plan	and/or	committee meeting where the Blockchain
		is in line with Blockchain Program	observation	Program charter was reviewed.
		Charter.		3. Blockchain Project Plan
		2. Inquire with the Blockchain
		program management to determine
		the criteria of monitoring the
		individual project work plans to
		ensure the progress is measured
		against the Blockchain project plan.
Governance	Program		1. Inquire with the Blockchain	Inquiry,	1. Blockchain Program Charter (policies
and	Management	program management team to	Inspection,	and procedures)
Oversight		determine that the Blockchain	and/or	2. Evidence of Blockchain selection criteria
		implementation processes are	observation	within the Blockchain Program Charter
		evaluated on a quarterly basis and		3. Blockchain implementation processes
		to ensure they adhere to the		4. Blockchain implementation evaluation
		Blockchain selection criteria		report
		outlined in the Blockchain Program
		Charter.
		2. Inquire with Steering Committee
		to ensure they receive the
		evaluation of the Blockchain
		implementation processes.
Governance	Program		1. Inspect the Blockchain	Inquiry,	1. Blockchain Configuration and
and	Management	Configuration and Maintenance	Inspection,	Maintenance Methodology
Oversight		methodology to ensure formal	and/or	2. Evidence of decision making criteria to
		policies and procedures have been	observation	go live
		documented and include decision		3. Evidence of review and approval of the
		making criteria to go live.		Blockchain Configuration and Maintenance
		2. Inspect the Blockchain		Methodology on a periodic basis
		Configuration and Maintenance
		methodology to ensure the policies
		and procedures have been reviewed
		and approved on a periodic basis.
Governance	Program		1. Obtain and inspect the	Inquiry,	1. Blockchain program policies and
and	Management	Blockchain program policies and	Inspection,	procedures
Oversight		procedures, and review for details	and/or	2. Evidence of review and approval on a
		of the formal the Blockchain	observation	periodic basis of the Blockchain program
		organization structure, staffing and		policies and procedures.
		training requirements.
		2. Inquire with management and
		inspect the policies and procedures
		to confirm that they have been
		reviewed and approved on a
		periodic basis.
Governance	Program		1. Inquire with management about	Inquiry,	1. Risk assessment performed by
and	Management	the process to evaluate the risks	Inspection,	management
Oversight		regarding loss of institutional	and/or
		knowledge.	observation
		2. Obtain and inspect the risk
		assessment performed by
		management, review that the risk
		has been evaluated.
Governance	Program		1. Inquire with management about	Inquiry,	1. Formal people and change process
and	Management	the people and change process.	Inspection,	document
Oversight
		2. Obtain and inspect the formal	and/or
		people and change process.	observation
Governance	Program
	1. Inquire with management	Inquiry,	1. Blockchain Program Charter
and	Management	regarding the formal process to	Inspection,	2. Evidence that evaluation of the change
Oversight		address organizational changes.	and/or	process is evaluated and presented to the
		2. Obtain and inspect the	observation	Blockchain steering committee.
		Blockchain Program Charter to
		confirm that is outlines a formal
		process to address organizational
		changes.
		3. Inquire with the Blockchain
		program management team to
		confirm that the change process is
		analyzed and evaluated on a
		monthly basis.
		4. Inquire with Blockchain steering
		committee to confirm that results of
		the evaluation are reported.
Governance	Program		1. Inquire with management on the	Inquiry,	1. Integration procedures for vendors
and	Management	integration procedure in place for	Inspection,
Oversight		new vendor software.	and/or
		2. Obtain and inspect the integration	observation
		plan and review to confirm that the
		Blockchain program management
		team
Governance	Program
	1. Inquire with management on the	Inquiry,	1. Documentation and evaluation of
and	Management	documentation and evaluation of	Inspection,	hardware, applications, software and
Oversight		hardware, applications, software	and/or	software components related to the
		and software components related to	observation	Blockchain
		the Blockchain.		2. Evidence of evaluation reported to the
		2. Obtain and inspect the formal		Blockchain Program steering committee.
		documentation and evaluation of
		hardware, applications, software
		and software components related to
		the Blockchain.
		3. Inspect evidence that the results
		of the evaluation are presented and
		reported to the Blockchain Program
		steering committee.
Governance	Program		1. Inquire with management on	Inquiry,	1. Policies and procedures to create the
and	Management	policies and procedures to create the	Inspection,	functional specifications.
Oversight		functional specifications.	and/or	2. Evidence that the process was reviewed
		2. Obtain and inspect the policies	observation	and approved.
		and procedures to create the
		functional specifications.
		3. Inspect evidence that the process
		is reviewed and approved on a
		periodic or as needed basis.
Governance	Program		1. Inquire and inspect the	Inquiry,	1. Blockchain Program Charter
and	Management	Blockchain Program Charter to	Inspection,	2. Evidence that the Blockchain Program
Oversight		confirm details regarding the	and/or	Charter was reviewed and approved.
		Benefits Management process.	observation
		2. Inspect that the Blockchain
		Program Charter has been reviewed
		and approved by the Blockchain
		program steering committee.
Governance	Project		1. Inquire with management on the	Inquiry,	1. Functional specifications
and	Management	process and appropriateness of	Inspection,	2. Evidence that employees involved in the
Oversight		resources used to design functional	and/or	design are appropriate and possess the
		specifications and confirm that they	observation	proper qualifications
		are reviewed by the Blockchain
		program risk and compliance team.
		2. Inspect functional specifications
		to assure appropriateness of the
		design and operating effectiveness
		of controls.
Governance	Project		1. Inquire with management about	Inquiry,	1. Training plan
and	Management	the training requirements for	Inspection,	2. Training materials
Oversight		analysts involved with the	and/or
		functional and/or technical design.	observation
		2. Inspect training plan or training
		materials provided to analysts,
		including any on-going training.
Governance	Project		1. Inquire with management on	Inquiry,	1. Policies and procedures that provide a
and	Management	policies and procedures that provide	Inspection,	description of key Blockchain program
Oversight		a description of key Blockchain	and/or	management positions, responsibilities and
		program management positions,	observation	overall organization structure for
		responsibilities and overall		governance.
		organization structure for
		governance.
		2. Obtain and inspect the policies
		and procedures that provide a
		description of key Blockchain
		program management positions,
		responsibilities and overall
		organization structure for
		governance.
Governance	Project		1. Inquire with management on the	Inquiry,	1. Reviews performed to test completeness
and	Management	reviews performed to test	Inspection,	and accuracy of processing for the
Oversight		completeness and accuracy of	and/or	Blockchain transactions.
		processing for the Blockchain	observation
		transactions.
		2. Obtain and inspect the reviewed
		performed to test completeness and
		accuracy of processing for the
		Blockchain transactions.
Governance	Leadership		1. Verify the Blockchain Program	Inquiry,	1. Blockchain Program Charter
and	Commitment	Charter has been created and review	Inspection,	2. Meeting minutes from the Steering
Oversight		the overall goals and business	and/or	committee meeting where the Blockchain
		objectives. Review the members of	observation	Program charter was reviewed.
		the organization who have
		contributed to the Blockchain
		Program Charter to confirm
		appropriate leadership engagement.
		2. Inspect the Blockchain Program
		Charter to ensure the Steering
		committee has reviewed and
		approved it.
Governance	MIS and	1. Inspect the Blockchain project	Inquiry,	1. Blockchain Project Plan/roadmap
and	Metrics	plan/roadmap to confirm the	Inspection,	2. Evidence of formal process to monitor
Oversight		financial needs are outlined.	and/or	and report project costs
		2. Inquire with the Blockchain	observation		3. Evidence of performance metrics
		program management to determine
		there is a formal process to monitor
		project costs and measure
		performance in place.
		3. Inquire with the Blockchain
		steering committee to ensure the
		project costs are reported to them
		on a monthly basis.
Governance	MIS and	1. Obtain daily Blockchain	Inquiry,	1. Daily Blockchain Capacity, Availability,
and	Metrics	capacity, availability, and	Inspection,	and Performance Metrics
Oversight		performance metrics.	and/or	2. Evidence of daily review of the metrics
		2. Inquire with Blockchain	observation	by the Blockchain Operational
		Operational Management to		Management
		determine the criteria for reviewing		3. Evidence of reporting the metrics to the
		the metrics daily and inspect the		Blockchain Program Steering Committee
		evidence to ensure the metrics are
		reviewed daily and if there are
		deviations they are noted,
		researched and resolved.
		3. Inspect the evidence of the
		metrics to ensure they are reported
		monthly to the Blockchain Program
		Steering Committee.
Governance	Operational	1. Inquire with the Blockchain	Inquiry,	1. Blockchain Program Charter
and	and Capital	steering committee members to	Inspection,	2. Meeting minutes from the Steering
Oversight	Expenditure	determine criteria for financial	and/or	committee meeting where the Blockchain
	Oversight	needs are included in the	observation	Program charter was reviewed.
		Blockchain Program Charter.		3. Blockchain Project Plan/Roadmap
		2. Inspect the Blockchain Program		4. Evidence of each individual Blockchain
		Charter to ensure the Steering		project work stream's financial needs
		committee has reviewed and
		approved it.
		3. Inspect the Blockchain Project
		Plan/Roadmap to ensure the
		financial needs of each individual
		project work stream is included and
		outlined.
Governance	Operational	1. Obtain a copy of the	Inquiry,	1. Organizations plans and/or documents
and	and Capital	organizations process and/or plans	Inspection,	for allocation of funds
Oversight	Expenditure	for allocating resources and verify it	and/or
	Oversight	takes the following factors into	observation
		consideration:
		people, skills, experience and
		competence;
		resources needed for each step of
		the risk management process;
		the organization's risk processes,
		methods and tools to be used for
		managing risk;
		documented processes and
		procedures;
		information and knowledge
		management systems;
		training programs.
Governance	Operational	1. Inquire with the control owner	Inquiry,	1. Documentation for the most recent
and	and Capital	and confirm if the organization has	Inspection,	annual budget planning exercise.
Oversight	Expenditure	processes in place to identify	and/or	2. Evidence that the organization has
	Oversight	additional expertise needed to	observation	processes in place to identify additional
		improve information security		expertise needed to improve information
		defenses.		security defenses.
		2. Determine if the size and quality		3. Provide a list the organization's security
		of the organization's security staff		staff, including their positions and
		is adequately staffed and structured		expertise.
		handle the impact of staff turnover.
Governance	Operational	1. Inquire with management how	Inquiry,	1. Project management methodology or
and	and Capital	security is embedded in the project	Inspection,	process documentation.
Oversight	Expenditure	management process/lifecycle.	and/or	2. Population: System extract or register of
	Oversight	2. Obtain project methodology or	observation	projects
		process documentation and validate		3. For a sample of projects selected,
		that it considers security risks as		evidence of risk assessment activities being
		part of the process.		performed as part of the project
				management lifecycle.
				4. ISMS manual - Description of the
				security requirements department managers
				are to include in projects.

In some embodiments, cybersecurity risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance surrounding the cybersecurity and privacy management activities.
The sub-risk categories, control and testing objectives, test procedures and request lists for Cyber Security risk category are provided below in Tables 5-7. The tables below are formatted in the same manner as tables 2-4 described above, and thus for an explanation of each column below, the corresponding discussion above can be referenced.

TABLE 5

					Risk Level (L,
		Risk	Risk		M, H)
Risk Category	Domain	Classification	Number	Risk Description	(As applicable)

Cyber Security	Cloud Security	Strategic,	CS-CS1	Without clearly defined roles	L, M, H
		Operational,		and responsibilities with cloud
		Financial,		service providers and SLA in
		Compliance,		place, accountability is lost
		Legal, or		when issues in the relationship
		Reputational		arise.
Cyber Security	Cloud Security	Strategic,	CS-CS2	Without clearly defined roles	L, M, H
		Operational,		and responsibilities with cloud
		Financial,		service providers and SLA in
		Compliance,		place, accountability is lost
		Legal, or		when issues in the relationship
		Reputational		arise.
Cyber Security	Cloud Security	Strategic,	CS-CS3	Lack of established and	L, M, H
		Operational,		implemented safeguards may
		Financial,		lead to supply chain
		Compliance,		information, system component,
		Legal, or		and information system
		Reputational		vulnerabilities
Cyber Security	Cloud Security	Strategic,	CS-CS4	Lack of adherence to the	L, M, H
		Operational,		documented production
		Financial,		network standards may lead to
		Compliance,		increased security risk.
		Legal, or
		Reputational
Cyber Security	Cloud Security	Strategic,	CS-CS5	Unauthorized access of	L, M, H
		Operational,		information stored in shared
		Financial,		resources can result in
		Compliance,		inappropriate access, changes or
		Legal, or		loss.
		Reputational
Cyber Security	Data Security	Strategic,	CS-DS1	Data exchanged through	L, M, H
		Operational,		communication facilities may
		Financial,		be intercepted and accessed by
		Compliance,		unauthorized agents within or
		Legal, or		outside the organizations
		Reputational		network.
Cyber Security	Data Security	Strategic,	CS-DS2	Procedures which do not	L, M, H
		Operational,		facilitate appropriately
		Financial,		classifying, labeling and
		Compliance,		handling information based on
		Legal, or		its value, business and legal
		Reputational		requirements may expose
				information to deliberate or
				accidental misuse.
Cyber Security	Data Security	Strategic,	CS-DS3	Lack of controls to protect	L, M, H
		Operational,		information can lead to data
		Financial,		leaks or exposures that threaten
		Compliance,		the organization's reputation
		Legal, or		and could lead to litigation.
		Reputational
Cyber Security	Data Security	Strategic,	CS-DS4	Lack of alignment with the	L, M, H
		Operational,		organization's risk strategy and
		Financial,		risk appetite in the protection of
		Compliance,		data may compromise the
		Legal, or		confidentiality, integrity and
		Reputational		availability of information in
				Blockchain systems.
Cyber Security	Data Security	Strategic,	CS-DS5	Failure to establish and	L, M, H
		Operational,		communicate policies and
		Financial,		procedures for information
		Compliance,		security relevant to Blockchain
		Legal, or		use case may result in gaps in
		Reputational		security capabilities needed to
				reduce the organization's cyber
				risk exposure in accordance
				with its risk appetite.
Cyber Security	Data Privacy	Strategic,	CS-DP1	Lack of controls to protect	L, M, H
		Operational,		information can lead to data
		Financial,		privacy or exposures that
		Compliance,		threaten the organization's
		Legal, or		reputation and could lead to
		Reputational		litigation.
Cyber Security	Data Privacy	Strategic,	CS-DP2	Failure to establish and	L, M, H
		Operational,		communicate policies and
		Financial,		procedures for privacy may
		Compliance,		result in gaps in privacy
		Legal, or		capabilities needed to reduce
		Reputational		the organization's privacy risk
				exposure in accordance with its
				risk appetite.
Cyber Security	Data Privacy	Strategic,	CS-DP3	Lack of a privacy policy may	L, M, H
		Operational,		increase the risk that
		Financial,		information is disclosed or used
		Compliance,		without the owner's consent,
		Legal, or		resulting in litigation and
		Reputational		reputational damage.
Cyber Security	Penetration	Strategic,	CS-PT1	Inadequately defined processes	L, M, H
	Testing	Operational,		for technical vulnerability
		Financial,		management and ineffective
		Compliance,		testing or detection of
		Legal, or		vulnerabilities may result in
		Reputational		inappropriate or unauthorized
				access to information.
Cyber Security	Network	Strategic,	CS-NS1	Failure to protect network	L, M, H
	Security	Operational,		perimeter may result in
		Financial,		unauthorized access.
		Compliance,
		Legal, or
		Reputational
Cyber Security	Patch and	Strategic,	CS-PVM1	Lack of proper information	L, M, H
	Vulnerability	Operational,		system management flaw
	Management	Financial,		management may result in
		Compliance,		security vulnerabilities
		Legal, or
		Reputational
Cyber Security	Patch and	Strategic,	CS-PVM2	Inadequately defined processes	L, M, H
	Vulnerability	Operational,		for technical vulnerability
	Management	Financial,		management and ineffective
		Compliance,		testing or detection of
		Legal, or		vulnerabilities may result in
		Reputational		inappropriate or unauthorized
				access to information.
Cyber Security	Patch and	Strategic,	CS-PVM3	Inadequate processes for system	L, M, H
	Vulnerability	Operational,		updates and patch management
	Management	Financial,		may result in compromise of
		Compliance,		system security due to the latest
		Legal, or		updates and patches not being
		Reputational		installed in a timely manner.
Cyber Security	Threat	Strategic,	CS-TD1	The lack of logging	L, M, H
	Detection	Operational,		mechanisms results in the
		Financial,		inability to track unauthorized
		Compliance,		activity.
		Legal, or
		Reputational
Cyber Security	Threat	Strategic,	CS-TD2	Inadequate processes for	L, M, H
	Detection	Operational,		logging and monitoring
		Financial,		Blockchain system activities
		Compliance,		may result in unauthorized
		Legal, or		information processing
		Reputational		activities going undetected.
Cyber Security	Threat	Strategic,	CS-TD3	Lack of monitoring mechanisms	L, M, H
	Detection	Operational,		may result in breaches and
		Financial,		sensitive data exposure.
		Compliance,
		Legal, or
		Reputational
Cyber Security	Threat Response	Strategic,	CS-TR1	Absence of a formalized	L, M, H
		Operational,		Security Incident Response
		Financial,		Program may result in
		Compliance,		uncoordinated processes in
		Legal, or		response to a security incident.
		Reputational
Cyber Security	Threat Response	Strategic,	CS-TR2	Absence of a formalized	L, M, H
		Operational,		Security Incident Response
		Financial,		Program may result in
		Compliance,		uncoordinated processes in
		Legal, or		response to a security incident.
		Reputational
Cyber Security	Threat Response	Strategic,	CS-TR3	Incidents that are not controlled	L, M, H
		Operational,		may lead to pervasive problems
		Financial,		throughout the organization.
		Compliance,
		Legal, or
		Reputational
Cyber Security	Programming	Strategic,	CS-PS1	In adequate security measures	L, M, H
	Security	Operational,		within the development
		Financial,		lifecycle of information systems
		Compliance,		may lead to unauthorized
		Legal, or		changes.
		Reputational
Cyber Security	Programming	Strategic,	CS-PS2	Systems with vulnerabilities	L, M, H
	Security	Operational,		may be developed and
		Financial,		implemented in the production
		Compliance,		environment.
		Legal, or
		Reputational
Cyber Security	Programming	Strategic,	CS-PS3	Systems with vulnerabilities	L, M, H
	Security	Operational,		may be developed and
		Financial,		implemented in the production
		Compliance,		environment.
		Legal, or
		Reputational
Cyber Security	Programming	Strategic,	CS-PS4	Systems with vulnerabilities	L, M, H
	Security	Operational,		may be developed and
		Financial,		implemented in the production
		Compliance,		environment.
		Legal, or
		Reputational
Cyber Security	Programming	Strategic,	CS-PS5	Untested changes may lead to	L, M, H
	Security	Operational,		interruption and/or unintended
		Financial,		consequences to the
		Compliance,		organization.
		Legal, or
		Reputational
Cyber Security	Programming	Strategic,	CS-PS6	Insecure coding practices,	L, M, H
	Security	Operational,		especially within the application
		Financial,		layer, can introduce security
		Compliance,		vulnerabilities and increase the
		Legal, or		risk to internal and external
		Reputational		threats.
Cyber Security	Programming	Strategic,	CS-PS7	Use of production or live data	L, M, H
	Security	Operational,		for development and/or testing
		Financial,		purposes can cause unintended
		Compliance,		corruption or manipulation of
		Legal, or		the data.
		Reputational
Cyber Security	Smart Contracts	Strategic,	CS-SM1	Input validation mechanisms for	L, M, H
		Operational,		fields and records are not in
		Financial,		place, creating the risk of failed
		Compliance,		conversion of data from input to
		Legal, or		outputs
		Reputational

TABLE 6

				In-scope/Out-of-
				Scope
		Control/Test		(TBD - As per
Risk Category	Domain	Objective	Control Description	engagement)

Cyber Security	Cloud Security	Contracts with the Cloud	Contracts between the Cloud	In-scope
		Service provider specify	Service Provider and the
		required information	organization specifies appropriate
		security and processing	security and processing measures,
		measures.	and establish data are not
			processed for any non-specified
			purpose without approval.
Cyber Security	Cloud Security	Cloud service providers	A contract is signed between both	In-scope
		and understand roles &	parties detailing the roles and
		responsibilities,	responsibilities of each party,
		including requirements to	including information security
		address information	requirements, confidentiality/non-
		security risks for	disclosure agreements,
		confidentiality, and the	obligations, and the obligations of
		secure transfer of	employees and subcontractors.
		information.
Cyber Security	Cloud Security	The organization	Organizational safeguards such as	In-scope
		employs measures to	the identification, management
		protect against supply	and reduction of vulnerabilities
		chain threats from cloud	are employed to protect the
		service providers that	supply chain against information
		impact the Blockchain	system, system components, and
		information system,	information system services
		system component, or	threats.
		information system
		service.
Cyber Security	Cloud Security	Cloud services are	Secure standardized network	In-scope
		secured using standard	protocols are in place to manage
		network protocols, and	the cloud service and
		interoperability and	documentation detailing relevant
		portability standards are	interoperability and portability
		available to customers.	standards are made available to
			customers.
Cyber Security	Cloud Security	Blockchain systems are	The Blockchain system are	In-scope
		configured to prevent	configured to prevents
		unauthorized access and	unauthorized and unintended
		transfer of information	information transfer via shared
		through shared system	system resources. Re-use of
		resources.	shared resources is monitored and
			controlled to prevent
			unauthorized access.
Cyber Security	Data Security	Data exchange is	Formal information exchange	In-scope
		controlled, encrypted,	requirements have been
		and protected while the	established and Blockchain
		information is at rest or	systems are configured to protect
		transferred between	the exchange of information
		systems.	through the use of all types of
			communication facilities and
			interfaces.
Cyber Security	Data Security	Resources (e.g.,	Information assets (e.g.,	In-scope
		hardware, devices, data,	hardware, devices, data, and
		and software) are	software) are classified based on
		classified based on their	their criticality and sensitivity.
		criticality and business	Information is handled and
		value.	protected in accordance with its
			classification, criticality, and
			business value to the
			organization.
Cyber Security	Data Security	Protections against data	The organization employs data	In-scope
		leaks are implemented.	mining prevention and detection
			techniques for data storage
			objects supporting Blockchain
			use case to adequately detect and
			protect against data mining.
Cyber Security	Data Security	Data in Blockchain	Information and records (data) in	In-scope
		systems is protected	Blockchain systems are managed
		according to the risk	consistent with the organization's
		strategy and risk appetite	risk strategy to protect the
		of the organization.	confidentiality, integrity, and
			availability of information.
Cyber Security	Data Security	Policies and procedures	Information security policies and	In-scope
		for direction and support	applicable procedures have been
		of organizational systems	formally documented in
		and applications exist in	accordance with organization's
		accordance with business	risk objectives, applicable legal
		requirements and	and regulatory requirements, have
		relevant laws and	been approved by Management,
		regulations.	and have been communicated to
			all employees and relevant
			external parties. The policies and
			procedures are reviewed on a
			periodic basis based on changes
			to the internal and external
			environment and to support
			management's objective of
			continuous improvement of the
			organization's information
			security capabilities.
Cyber Security	Data Privacy	Protections against data	Unauthorized leaks of data,	In-scope
		privacy are implemented	specifically PII and PHI, are
		in Blockchain systems to	prevented or detected. The
		prevent unauthorized	processor prevents or monitors
		view or exposures of	for unauthorized leakage of data,
		confidential information.	or enables the capability for its
			customers to prevent or monitor
			for the unauthorized leakage of
			data. DLP tools monitor
			outbound communications traffic
			at the external boundary of the
			information system (i.e., system
			perimeter) and at interior points
			within the system (e.g.,
			subsystems, subnetworks) to
			detect covert exfiltration of
			information.
Cyber Security	Data Privacy	Policies and procedures	Information security policies and	In-scope
		for direction and support	procedures around information
		of information privacy	privacy are documented and
		exist in accordance with	available to personnel on
		business requirements	accessible resources. The policies
		and relevant laws and	and procedures are
		regulations.	reviewed/updated periodically.
Cyber Security	Data Privacy	The organization	The privacy policy discloses the	In-scope
		discloses how it uses PII	ways that the organization
		in accordance with the	gathers, uses, discloses, and
		public notice	manages PII. It fulfills the legal
		requirement.	requirement to protect PII and
			declares the company's policy on
			how it collects, stores, and
			releases the PII it collects, and
			inform whether PII is kept
			confidential, shared with partners,
			or sold to other firms or
			enterprises.
Cyber Security	Penetration	Asset vulnerabilities are	Penetration tests of the	In-scope
	Testing	monitored, identified and	production environment are
		documented.	performed on a periodic basis or
			after any significant infrastructure
			or application upgrade or
			modification. Remediation plans
			are developed to address the
			risks. The penetration testing
			methodology aligns with industry
			standard practices and covers
			application-layer and network-
			layer. Testing is performed both
			inside and outside the network.
			Test results are retained for a
			specific period of time.
Cyber Security	Network	Network perimeter is	Firewalls and routers are	In-scope
	Security	protected using managed	configured to:
		boundary protection	Restrict inbound and outbound
		devices.	traffic to that which is necessary
			(e.g., deny by default, permit by
			exception)
			Restrict connections between
			untrusted networks and any
			system components
			Fail securely in case of an
			operational failure
			Permit only authorized traffic
			between wireless environment
			and cardholder data environment
			Firewall and router configuration
			standards are in place to define
			network connection requirements.
			The firewall and router
			configuration standards include
			the following:
			Business justification and
			approval for use of all services,
			protocols, and ports allowed,
			including security features
			implemented for those protocols
			considered to be insecure (e.g.,
			FTP, Telnet, POP3, IMAP, and
			SNMP v1 and v2)
			Roles and responsibilities for
			management of network
			components.
			Exceptions to the standards are
			documented and reviewed on a
			periodic basis.
			There is a formal process for
			testing and approval of all
			network connections and changes
			to firewall and router
			configurations.
			For any public-facing Web
			applications, an automated
			technical solution that detects and
			prevents web-based attacks (for
			example, a web-application
			firewall) has been installed, to
			continually check all traffic.
			A DMZ is implemented to limit
			inbound traffic to only system
			components that provide
			authorized publicly accessible
			services, protocols, and ports.
			Inbound Internet traffic is limited
			to IP addresses within the DMZ.
			A firewall is required at each
			internet connection and between
			any DMZ and the intranet.
			The information system routes
			internal communications traffic to
			external networks through
			authenticated proxy servers (e.g.,
			web content filters with a defined
			list of authorized and
			unauthorized websites)
			Anti-spoofing measures are
			implemented to detect and block
			forged source IP addresses from
			entering the network.
Cyber Security	Patch and	Identify, report and	A vulnerability management	In-scope
	Vulnerability	correct information	program exists to identify and
	Management	systems flaws in a timely	manage vulnerabilities in a
		manner.	centralized, streamlined and
			organized manner. The technical
			vulnerability management
			program is evaluated on a
			quarterly basis.
Cyber Security	Patch and	System vulnerability	Vulnerability scans and rescans	In-scope
	Vulnerability	scanning is performed to	are performed by qualified
	Management	identify threats.	personnel on both external and
			internal facing production
			systems using internal scanning
			resources on a periodic basis and
			when new vulnerabilities
			affecting the systems are known.
			Commercial and proprietary
			vulnerability scanning tools are
			configured to identify
			vulnerabilities. Identified critical
			vulnerabilities are remediated
			timely. Remediation status is
			monitored and non-compliance is
			escalated.
Cyber Security	Patch and	System vulnerabilities	A patch management program	In-scope
	Vulnerability	are mitigated through	exists to incorporate, test, and
	Management	patches.	implement firmware updates and
			patches in a timely fashion
Cyber Security	Threat Detection	Logging mechanisms and	Logging mechanisms are	In-scope
		the ability to track	configured to enable the
		activity is established,	monitoring, analysis,
		tracked, and monitored.	investigation, and reporting of
			unlawful, unauthorized, or
			inappropriate information system
			activity: The following events are
			tracked:
			General user access and
			activities
			Root access and activities
			Access to audit logs
			Invalid access attempts
			Changes to identification and
			authentication mechanisms
			Changes to or elevation of
			privilege access rights
			Initialization, stopping, or
			pausing of the audit logs
			Creation and deletion of system-
			level objects
			exceptions
			system faults
			information security events
			system/network events
			For each event, the following
			details are captured:
			Type of event
			Time
			Where the event occurred
			Source of the event
			Outcome of the event
			(success/failure)
			Unique identity of individuals
			associated with the event
			Identity or name of affected
			data, system component, or
			resource.
Cyber Security	Threat Detection	Risk-based monitoring to	Risk based monitoring is	In-scope
		detect unauthorized	performed using automated tools
		connections, devices,	(e.g., SIEM tools) to detect
		events, and network	unauthorized connections,
		services.	devices, events, and network
			services. Automated tools are
			used to perform analysis of
			events. Monitoring is performed
			in compliance with legal and
			regulatory requirements. Events
			are analyzed to understand attack
			targets and methods.
Cyber Security	Threat Detection	Automated mechanisms	The organization employs	In-scope
		communicate security	automated mechanisms to make
		alert and advisory	security alert and advisory
		information following	information available throughout
		indicators of	the organization when indicators
		compromise.	of compromise are found.
Cyber Security	Threat Response	Incident response	A formal security incident	In-scope
		program is in place to	response program is established
		provide timely and	to respond, report, escalate and
		effective response to user	treat breaches and reported
		requests and resolution to	security events or incidents. A
		all types of incidents.	comprehensive incident response
			plan exists to identify, manage,
			respond to, and recover from
			security (e.g., system breach) and
			IT operational (e.g., process
			errors) incidents and is
			communicated to appropriate
			stakeholders. The incident
			response plan is reviewed and
			modified on a periodic basis.
Cyber Security	Threat Response	Incident response	The organization develops,	In-scope
		program is in place to	documents, and disseminate an
		provide timely and	incident response policy. The
		effective response to user	policies and procedures are
		requests and resolution to	reviewed and updated, at a
		all types of incidents.	minimum, on an annual basis.
Cyber Security	Threat Response	Security incidents are	Incident alert thresholds have	In-scope
		contained and mitigated	been established and all incident
		to prevent additional	detection tools have been
		impact to business	calibrated with the thresholds.
		operations and loss of	Incidents (operational or IT
		information.	security) are identified, logged,
			documented, reported to different
			levels within the organization,
			and tracked to closure.
Cyber Security	Programming	Organizations should	The organization establishes and	In-scope
	Security	establish and	appropriately protects secure
		appropriately protect	development environments for
		secure development	system development and
		environments for system	integration efforts that cover the
		development and	entire system development
		integration efforts that	lifecycle.
		cover the entire system
		development lifecycle.
Cyber Security	Programming	Systems are developed	An established system	In-scope
	Security	securely.	development lifecycle (SDLC)
			process and methodology is in
			place, documented, maintained,
			and applied for system and
			software design, acquisition,
			implementation, configuration,
			integration, testing, modification,
			and maintenance. The process
			also specifies the tools to be used
			for system development. The
			secure SDLC process,
			methodology, and tools are
			reviewed on a periodic basis.
Cyber Security	Programming	Systems are developed	The SDLC process is inclusive of	In-scope
	Security	securely.	information security
			considerations. Security roles and
			responsibilities during the
			development lifecycle have been
			defined. Organization's
			information security team and the
			risk management methodology is
			appropriately integrated into the
			SDLC process.
Cyber Security	Programming	Systems are developed	The Security team coordinates	In-scope
	Security	securely.	with the system developers to
			define and develop system
			security plans. System security
			plans that outline the security
			requirements are documented and
			maintained for information
			systems. The plans are
			communicated to relevant and
			authorized internal and external
			users.
Cyber Security	Programming	Test data should be	Test data shall be selected	In-scope
	Security	selected carefully,	carefully, protected and
		protected and controlled.	controlled. Operational data is
			protected when used for test
			purposes. Test data and accounts
			are removed from system
			components before the system
			becomes active/goes into
			production.
Cyber Security	Programming	Applications should be	Developers employ secure coding	In-scope
	Security	developed using secure	guidelines to software and mobile
		coding guidelines, in	applications. Developers are
		order to address common	trained at least annually in up-to-
		coding vulnerabilities.	date secure coding techniques,
			including how to avoid common
			coding vulnerabilities. (Refer the
			OWASP Guide, SANS CWE Top
			25, CERT Secure Coding, etc.)
Cyber Security	Programming	Production data are not	Production data are not used for	In-scope
	Security	used for testing or	testing or development.
		development.

TABLE 7

Risk			Test Type (TBD - As
Category	Domain	Test Procedure (#)	per engagement)	Request List (#)

Cyber	Cloud Security		1. Obtain and review contracts with cloud	Inquiry, Inspection,	1. Contracts with
Security		service providers to determine whether contracts	and/or observation	cloud service
		include information security provisions to		providers.
		protect against cybersecurity and data
		security/data privacy risks.
Cyber	Cloud Security		1. Inquire with the control owner and determine	Inquiry, Inspection,	1. Policies and
Security		if all relevant information security requirements	and/or observation	procedures related to
		are established and agreed with each supplier/		contracts between the
		vendor that may access, process, store,		organization and
		communicate, or provide IT infrastructure		suppliers/vendors.
		components for, the organization's information.		2. Evidence of
		2. Inspect a sample of agreements and validate		agreements between
		that they include the following:		the organization and
		Roles and responsibilities		suppliers/vendors.
		Service definitions and SLAs		3. Population -
		Information security controls to be		System generated list
		implemented		of contract
		System functions, ports, protocols, and other		amendments during
		services required for the use of such services.		the audit period.
		Requirement to provide notification of changes		2. Evidence that a new
		to services or controls		customer or vendor
		Requirement to provide notification of 3rd		contract addendum or
		party personnel transfers and terminations		new vendor contract
		Laws and regulations that the third party needs		was signed for a
		to comply with		sample of changes to
		Penalties or claw back clauses		confidentiality
		Locations that they can provide services out of		commitments
		Limitations on data storage locations		requiring customer or
		Incident management procedures		vendor notification.
		Breach notification
		Right to audit
		Limitations and constraints of access
		Termination conditions
		Data disposal/return upon termination
		Ownership of products after development
		Quality requirements
		Security training requirements for employees
		Business-critical or customer-impacting
		application design, development, and
		deployment
		Business-critical or customer-impacting
		system designs and configurations design,
		development, and deployment
		Business-critical or customer-impacting
		infrastructure network and system components
		design, development, and deployment
		IT Governance and service management
		policies and procedures
		Customer requirements policies and
		procedures for service-to-service application
		Customer requirements policies and
		procedures for information processing,
		interoperability, and portability for application
		development
		Customer requirements policies and
		procedures for information exchange, usage, and
		integrity persistence
		3. Inquire with the control owner to determine if
		confidentiality commitments with vendors/
		suppliers are changed during the normal course
		of business. If changes to confidentiality
		commitments are required, verify through
		inquiry with the control owner that a vendor
		contract addendum or new vendor contract is
		established.
		4. Obtain the population of tickets related
		changes to confidentiality commitments
		requiring vendor/supplier notification.
		5. For a sample from the above #4 population,
		verify that a vendor contract addendum or new
		vendor contract was signed.
Cyber	Cloud Security		1. Inquire with the control owners and observe	Inquiry, Inspection,	1. System and
Security		the organization's processes for defining the	and/or observation	services acquisition
		safeguards that protect systems against supply		policies and
		chain threats, as well as the automated		procedures.
		mechanisms supporting supply chain threat		2. Procedures for the
		safeguards. Determine if the organization		integration of security
		protects its information systems, system		requirements into the
		components, or information system services		development process.
		from supply chain threats by implementing		3. Service delivery
		security safeguards as defined by the information		agreements
		security strategy.
		2. Inspect system and services acquisition
		policies and procedures, procedures for the
		integration of security requirements into the
		development process, and supporting
		documentation to determine the following:
		if the organization defines the security
		safeguards to implement as protection to
		information systems, system components, or
		system services against supply chain threats.
		if the organization assures reasonable
		information security across their information
		supply chain by performing annual reviews,
		including reviews of all partners and third-party
		providers that the organization's information
		supply chain depends on.
		3. Inspect service delivery agreements and
		determine the following:
		that third party service providers are required to
		demonstrate compliance with information
		security and confidentiality, access control,
		service definitions, and delivery-level
		agreements defined.
		that third-party reports, records, and services
		shall undergo audit and review at least annually
		to govern and maintain compliance with the
		service delivery agreements.
Cyber	Cloud Security		1. Inquire with the control owner and determine	Inquiry, Inspection,	1. Cloud service
Security		the following:	and/or observation	policies and
		The organization uses secure standardized		procedures
		network protocols (e.g., non-clear text and
		authenticated) to manage services.
		The organization makes available to
		customers documentation detailing relevant
		interoperability and portability standards.
		If the organization, as a cloud service
		provider, uses an industry-recognized
		virtualization platform and standard
		virtualization format to help ensure
		interoperability.
		if any custom changes made to any
		hypervisor in use and to all solution-specific
		virtualization hooks are documented and made
		available to customers for review.
		2. Inspect cloud service security policies and
		procedures and determine the following:
		The organization uses secure standardized
		network protocols (e.g., non-clear text and
		authenticated) to manage services.
		The organization makes available to
		customers documentation detailing relevant
		interoperability and portability standards
		The industry-recognized virtualization
		platforms and standard virtualization formats are
		used to help ensure interoperability.
		The custom changes made to any hypervisor
		in use and to all solution-specific virtualization
		hooks shall be documented and made available
		to customers for review.
Cyber	Cloud Security		1. Determine through inquiry with control owner	Inquiry, Inspection,
Security		whether processes are in place to remove any	and/or observation
		previous content from shared resources when it
		is being allocated for reuse to new set of users.
Cyber	Data Security		1. Confirm the following have been addressed	Inquiry, Inspection,
Security		within policies and procedures for the use of	and/or observation
		electronic communication facilities:
		procedures designed to protect exchanged
		information from interception, copying,
		modification, incorrect routing, and destruction
		procedures for the detection of and protection
		against malicious code that may be transmitted
		through the use of electronic communications
		procedures for protecting communicated
		sensitive electronic information that is in the
		form of an attachment, policy or guidelines
		outlining acceptable use of electronic
		communication facilities
		procedures for the use of wireless
		communications, employee, contractor and any
		other users' responsibilities not to compromise
		the organization, use of cryptographic
		techniques, retention and disposal guidelines for
		all business correspondence in accordance with
		relevant national and local legislation and
		regulations, not leaving sensitive or critical
		information on printing facilities
		controls and restrictions associated with the
		forwarding of communication facilities, not
		leaving messages containing sensitive
		information on answering machines, reminding
		personnel not to register demographic data in
		any software to avoid collection for unauthorized
		use.
Cyber	Data Security		1. Inquire with the control owner to determine	Inquiry, Inspection,	1. Data Classification
Security		whether the business value of each information	and/or observation	Policy and
		asset has been established and documented.		procedures.
		2. Inquire with the control owner and obtain the		2. Evidence that
		Data Classification Guide to determine if		critical assets have
		classification schemes and procedures for		been identified and
		handling, processing, storing and communicating		documented.
		information consistent with its classification,		3. Evidence that the
		criticality, and business value are documented.		security categorization
		3. Inquire with the control owner to determine		decision is reviewed
		whether critical assets have been identified and		and approved by the
		documented.		authorizing official or
		4. Determine whether logical and physical		authorizing official
		protection levels offered for data stored in		designated
		databases, removable media, etc. is in alignment		representative.
		with the classification level of the data.		4. Sample of media to
		5. Inspect if the security classification decision is		determine whether
		reviewed and approved by an authorizing official		they have been
		or authorizing official designated representative.		classified so that
		6. Inspect if all media has been classified so that		sensitivity of the data
		the sensitivity of the data can be determined.		can be determined.
		7. Validate whether all assets have been assigned		5. Evidence that assets
		an owner.		are assigned to an
				owner.
Cyber	Data Security		1. Obtain and inspect relevant documents to	Inquiry, Inspection,	1. Account
Security		determine if the organization implements various	and/or observation	Management
		data mining protection program for the		Procedures.
		information system, system component, or		2. Information
		information system service.		Security technical
		For example:		standard.
		limiting the types of responses provided to		3. Access
		database queries;		Management
		limiting the number/frequency of database		procedures.
		queries to increase the work factor needed to		4. Database access
		determine the contents of such databases; and		management
		notifying organizational personnel when		procedures.
		atypical database queries or accesses occur.
		2. Inquire with control owners to determine that
		established policies and procedures are in place
		and define data mining prevention and detection
		techniques, define that data storage objects are to
		be protected, and define the organization-defined
		techniques for data mining prevention and
		detection techniques for data storage
		3. Inspect the organizations Account
		Management Procedures, Information Security
		Technical Standard, Access Management
		Procedures, Database Access Management
		Procedure, and determine that the established
		policies and procedures outline and define data
		mining prevention and detection techniques and
		storage protection:
Cyber	Data Security		1. Obtain and inspect relevant documents to	Inquiry, Inspection,	1. Relevant policies
Security		determine if the organization aligns with its risk	and/or observation	and procedures.
		strategy and risk appetite when implementing		2. Evidence of review
		data protection measures.		(e.g., sign
		2. Inquire with control owners to determine that		off/approvals
		policies and procedures are in place that		documented in policy
		prescribe data protection measures based on		revisions history).
		information classification and risk ranking.		3. Screenshot of the
				location of policies
				and procedures
				showing that they are
				available to company
				personnel.
				4. Evidence showing
				that policies are part
				of annual security
				awareness.
Cyber	Data Security		1. Inquire with the control owner and determine	Inquiry, Inspection,	1. Relevant policies
Security		if information security policies and procedures	and/or observation	and procedures.
		are documented, available and communicated to		2. Evidence of review
		personnel on accessible resources (internal		(e.g., sign
		network, shared drive, etc.).		off/approvals
		2. Inspect policies and procedures to confirm if		documented in policy
		they are reviewed/updated at least annually or		revisions history).
		more frequently if required based on changes in		3. Screenshot of the
		the environment.		location of policies
		3. Security policies and operational procedures		and procedures
		should address organization-determined areas		showing that they are
		and best practices, examples include:		available to company
		Business Continuity/Disaster Recovery;		personnel.
		Data Protection/DLP;		4. Evidence showing
		Access Management;		that policies are part
		Vendor Management;		of annual security
		Physical Security;		awareness.
		SDLC;
		Security Awareness training;
		Mobile device management;
		Legal/regulatory requirements;
		System/service acquisition;
		User agreements.
		Incident Management
		Network Security
		Configuration Management
		Application Security
		Cryptography and Key Lifecycle Management
		Risk Assessment and Treatment
		Data confidentiality, integrity and availability
		across multiple system interfaces, jurisdictions,
		business functions
Cyber	Data Privacy		1. Inquire of management and obtain evidence to	Inquiry, Inspection,	Special Note:
Security		validate whether the organization has capabilities	and/or observation	Personally identifiable
		to prevent or monitor data leaks.		information (““PII””)
		2. Determine if the organization performs		and Protected Health
		activities to analyze potential opportunities for		Information (““PHI””)
		covert channels. If so, determine if testing is		fall under ““Customer
		performed to identify exploitable channels and		Data”” and is thus
		the bandwidth associated with those channels.		subjected to the
		3. Inquire with the control owner to determine if		company's data
		the above-mentioned capabilities in test		classification schema
		procedure #
1 are aligned with legislative,		and controls.
		regulatory, or contractual obligations,		1. Data Classification
		4. Obtain and inspect policies, procedures, and		and Protection
		other supporting documentation to validate		policies and
		whether the aforementioned capabilities in test		procedures.
		procedure #1 are in place to enable the		2. Policies and
		organization to meet their obligations to		procedures related to
		customers in accordance with contractual		Data Loss Prevention
		requirements.		and the handling of
				customer data.
				3. Evidence of the
				organizations
				capabilities to prevent
				or monitor data leaks.
				4. Evidence that data
				loss prevention
				processes and
				procedures are aligned
				with legislative,
				regulatory, or
				contractual
				obligations.
Cyber	Data Privacy	[General Privacy Requirements; Notice, Choice,	Inquiry, Inspection,	1. Privacy policies
Security		Consent]	and/or observation	and procedures
		1. Inquire with the control owner and determine		regarding
		where information security policies and		confidentiality and
		procedures are documented and available to		non-disclosures.
		personnel with access to PII on accessible		2. ISMS manual
		resources (internal network, shared drive, etc.).		(Executive
		2. Review policies and procedures to confirm		Leadership, CTO)
		they are reviewed/updated at least annually or		3. Evidence to
		more frequently if required based on changes in		demonstrate that
		the environment,		documents are
		3. Inspect the information security policies on		available to personnel
		the company's internal network and determine		with access to PII on
		they are available and communicated to		accessible resources
		company personnel with access to PII and		such as internal
		include security roles, responsibilities, and		network, shared drive,
		procedures. Specifically, privacy policies and		etc.
		operational procedures for the confidentiality		4. Data localization
		and non-disclosure agreements.		policy
		[Storage Location of PII]		5. List of countries
		1. Inquire with the control owner and determine		that might have access
		that the organization has documented data		to the organization's
		localization policies and procedures available to		customers' PII.
		personnel on accessible resources (company		6. Evidence
		intranet, shared drive).		documenting the
		2. Inspect the data localization policy on the		review and update
		company's internal network and determine they		procedures performed
		are available and communicated to company		by the organization to
		personnel and address that the organization		ensure that the list of
		documents and makes available the countries		countries is accurate
		where PII might be stored as required.		and up to date.
		3. Inspect policies and procedures to confirm
		they are reviewed and updated based on changes
		in the environment.
		4. Obtain and inspect the list of countries that
		might have access to the organization's
		customers' PII.
		5. Obtain and inspect the list of countries to
		determine the review and update procedures
		performed by the organization to ensure that the
		listing is accurate and up to date.
Cyber	Data Privacy		1. Inquire with control owners to understand	Inquiry, Inspection,	1. Data privacy policy
Security		where, within the organization's data policies,	and/or observation	showing the
		the expectations for the return, transfer, and/or		expectations for the
		destruction of PII is defined. In addition,		return, transfer, and/or
		determine how this is communicated to the		destruction of PII by
		customers (i.e. website, contract/amendments).		the organization for
		2. Obtain and observe the appropriate		the customers.
		documentation (i.e. data policy) showing the		2. Data Classification
		expectations for the return, transfer, and/or		policy for restricted
		destruction of PII by the organization for the		class protection.
		customers.
Cyber	Penetration		1. Inquire with the control owner to determine	Inquiry, Inspection,	1. Copy of most
Security	Testing	whether penetration tests are performed on a	and/or observation	recent penetration test
		periodic basis and remediation plans are		and penetration test
		developed to address the risks.		methodology utilized.
		2. Inspect the results of the most recent		2. Population of risks
		penetration test to determine whether it was		from most recent
		completed within the organization-specified time		penetration test.
		period and performed by an independent		3. For a sample of
		penetration agent or team.		risks, please provide
		3. Inspect ticket details and supporting		ticket/supporting
		documentation for a sample of risks identified in		details to document
		the most recent penetration test to determine		remediation.
		whether the risks were remediated or were being		4. Please provide
		actively worked to remediation.		evidence that both
				external and internal
				penetration tests are
				performed at least
				annually and after any
				significant
				infrastructure or
				application
				modification.
Cyber	Network		1. Inspect documented procedures and determine	Inquiry, Inspection,	1. Firewall and router
Security	Security	that there is a formal process for testing and	and/or observation	configuration
		approval of all:		standards
		Network connections; and		2. Evidence of
		Changes to firewall and router configurations		firewall rule review.
		2. Obtain a population of changes to network		3. Router rule sets
		connections, firewalls, and router configurations.		4. Network diagrams
		3. Select samples and obtain tickets.		5. Population of
		4. Inspect tickets from selected sample to		changes to network
		validate that changes to network connections,		connections, firewalls,
		firewalls, and router configurations were tested		and router
		and approved.		configurations.
		5. Validate whether the network diagrams are		6. Tickets for samples
		updated if there is a change in the network		of changes to network
		connection.		connections, firewalls,
				and router
				configurations.
				7. Population of
				firewall reviews, from
				which a sample will
				be selected.
				8. Evidence of
				firewall reviews for
				the sample selected.
Cyber	Patch and	1. Inquire with the control owner to determine if	Inquiry, Inspection,	1. Policies and
Security	Vulnerability	a formal vulnerability management program	and/or observation	procedures related to
	Management	exists and tools are in place to detect, report, and		vulnerability
		correct vulnerabilities.		management.
		2. Determine if there is a formally documented		2. Population of
		vulnerability management methodology and		vulnerability/patch
		procedures.		tickets.
		3. Through interviews with the control owner,		3. Sample evidence of
		inspection of reports, determine whether system		ticket resolution
		vulnerabilities are identified and tracked.		including risk ranking.
		4. Inspect tickets to determine if the vulnerability		4. Information
		was ranked, worked to resolution based on		Security Policies and
		criticality, authorized, tested, and approved prior		procedures.
		to implementation into production.
		5. Verify whether the program is evaluated on a
		quarterly basis.
Cyber	Patch and	1. Inquire with the control owner and determine	Inquiry, Inspection,	1. Evidence that
Security	Vulnerability	if vulnerability scans were performed on both	and/or observation	vulnerability scans
	Management	external and internal facing production systems		were performed on
		using internal scanning resources on an		both external and
		organization-defined frequency.		internal facing
		2. Inspect the internal scanning resource		production systems
		configurations and determine vulnerability scans		using internal
		were scheduled to run with an appropriate		scanning resources.
		frequency and were configured to run against		2. Scanning resource
		internal and external IP ranges.		configuration.
		3. Inspect the vulnerability scan report for a		3. Reference of
		sample of weeks and determine an internal and		internal IPs from a
		external vulnerability scan was completed in		source that is
		accordance with the configured schedule.		independent from the
		4. Inspect if the organization performs privileged/		team responsible for
		authenticated vulnerability scans		vulnerability scanning
		5. Inspect if the organization employs		4. Internal and
		vulnerability scanning procedures that can		external vulnerability
		identify the breadth and depth of coverage (i.e.,		scan reports for the
		information system components scanned and		for the selected weeks
		vulnerabilities checked).		(to be specified).
		6. Inspect if the organization employs
		vulnerability scanning procedures that updates
		the information system vulnerabilities scanned.
Cyber	Patch and	1. Determine the number of vulnerabilities	Inquiry, Inspection,	1. Obtain a listing of
Security	Vulnerability	identified.	and/or observation	application systems
	Management
	2. Validate that patch management process is		with vulnerabilities.
		initiated to address the known vulnerabilities.		2. Obtain a listing of
		3. Validate that patch is tested and applied timely		patches deployed to
		to mitigate the known vulnerabilities.		address identified
				vulnerabilities in a
				timely manner.
				3. Obtain evidence
				showing that the
				patches were tested
				before deployed into
				production
Cyber	Threat
	1. Inquire with the control owners and inspect	Inquiry, Inspection,	1. System generated
Security	Detection	evidence to validate whether or not the	and/or observation	list of production
		organization performs logging related to both		servers and network
		unauthorized actions and access. The following		devices as of present
		items are examples of logging mechanisms that		day with source, filter/
		should be in place:		query details, etc.
		Action-related logging events:		2. Log configurations
		all changes, additions, or deletions to any		for a sample of
		account with root or administrative privileges;		production servers
		Initialization, stopping, or pausing of audit		and network devices.
		logs;		3. Evidence that the
		creation and deletion of system level objects;		organization performs
		creation, modification, enabling, disabling, and		logging related to both
		removing of accounts;		unauthorized actions
		initialization and the stopping or pausing of		and access.
		audit logs.		4. Policies and
		system security configuration changes		procedures related to
		activation and de-activation of protection		access control,
		systems (e.g., A/V and IDS)		account management,
		management activities, system and application		audit and
		startup/shutdown/errors, file changes, and		accountability, storage
		security policy changes.		engineering, and audit
		Access-related logging events:		record content.
		successful and unsuccessful account logon		5. Evidence that the
		events;		organization
		all individual access to cardholder data;		configures
		access to all audit trails;		information systems
		elevation of privileges.		to allocate storage
		2. Inquire of management and inspect evidence		space for the retention
		to validate whether the organization:		of audit records.
		includes user identification, event type, date
		and time stamp, indication of success or failure,
		event origination, and identity of affected data,
		system component, or resources in log entries;
		monitors information system accounts for
		abnormal usage and activity;
		reports abnormal usage and activity on
		information system accounts to specified
		personnel;
		configures information systems to generate
		audit records that contain information on what
		type of event occurred, when and where the
		event occurred, the source and outcome of the
		event, and the identity of individuals associated
		with the event;
		continuously writes logs from production
		servers, network devices, databases and storage
		management hosts to system logs and forwards
		them to the logging and alerting system in real-
		time in order to provide backup media for
		records other than the audited system;
		configures the information system to provide
		the capability to generate audit records for
		defined auditable events for specified
		information system components;
		configures the information system to allow
		specified personnel to select which auditable
		events should be audited by specific system
		components;
		configures the information system to provide
		capabilities for specified individuals to change
		the performed audits on information system
		components based on defined selectable event
		criteria within specified thresholds.
		3. Inspect policies and procedures around access
		control, account management, audit and
		accountability, storage engineering, and audit
		record content and validate whether or not the
		organization.
		defines abnormal information system account
		usage and the personnel to be notified upon the
		identification of abnormal system usage;
		configures the information system to generate
		audit records that contain information on what
		type of event occurred, when and where the
		event occurred, the source and outcome of the
		event, and the identity of individuals associated
		with the event;
		defines the additional detailed information
		required to be included in audit records that the
		information system generates;
		defines the information system components that
		provide audit record generating capabilities for
		defined auditable events;
		defines the personnel whom are allowed to
		select which auditable events are to be audited
		by specified information system components,
		and change the validating performed on specified
		information system components;
		defines the information system components that
		validating is performed on;
		defines the time thresholds that must be met for
		specified individuals to change the audit
		functions performed on information system
		components;
		defines the event criteria that can be selected by
		specified individuals or roles to support the
		capabilities of changing audit functions
		performed on information system components;
		continuously writes logs from production
		servers, network devices, databases and storage
		management hosts to system logs and forwards
		them to the logging and alerting system in real-
		time in order to provide backup media for
		records other than the audited system
		4. Inspect audit record storage capacity related to
		information system configuration settings and
		determine that the organization configures
		information systems to allocate storage space for
		the retention of audit records and that it is
		sufficient in accordance to defined requirements.
Cyber	Threat		1. Inquire with the control owner to determine if	Inquiry, Inspection,	1. Evidence that the
Security	Detection	documented procedures for monitoring are in	and/or observation	organization monitors
		place to detect vulnerabilities, indicators of		the Blockchain
		potential attacks in accordance with		information system to
		(organization-defined) monitoring objectives,		detect unauthorized/
		unauthorized local, network, and remote		malicious activity.
		connections;		2. Provide a list of
		2. Inquire with the control owner to verify		tools and processes in
		whether monitoring tools are implemented in		place to monitor the
		high risk systems and environments to detect		Blockchain
		anomalous events and activities:		information system
		Inbound and outbound communications		and their
		Internal system activities, including		configurations.
		unauthorized system use and transactions		3. Provide a system
		Unauthorized connections		generated list of
		Unauthorized users		vulnerability tickets
		Unauthorized devices		for the period under
		Unauthorized software		review, from which a
		Unauthorized remote access connections		sample will be
		3. Verify whether action is taken as part of		selected.
		incident response and vulnerability management		4. Provide the internal
		plan when anomalous events are detected		tickets from the
		4. Inspect the monitoring tools to verify their		selected sample.
		configuration and validate whether they are
		configured to detect anomalous events.
Cyber	Threat		1. Inquire with management to determine if the	Inquiry, Inspection,	1. Information
Security	Detection	organization employs automated mechanisms to	and/or observation	security policies and
		make security alert and advisory information		procedures related to
		available throughout the organization.		security alerts and
		2. Inspection information security policies to		advisories.
		determine if the organization has defined		2. Evidence of
		requirements regarding automated mechanisms		processes in place for
		to make security alert and advisory information		defining, receiving,
		available throughout the organization.		generating, and
		3. Inspect organizational processes in place for		disseminating security
		defining, receiving, generating, and		alerts and advisories.
		disseminating security alerts and advisories,
		including automated mechanisms supporting
		and/or implementing dissemination of security
		alerts and advisories.
Cyber	Threat		1. Verify that a formal incident response	Inquiry, Inspection,	1. Information
Security	Response	program exists and includes formally defined	and/or observation	Security Incident
		roles and responsibilities, an incident response		Management
		plan, and resources to support incident response.		documentation
		2. Obtain the copy of the incident response plan.		2. CSIRT/Incident
		Verify that it is formally documented and has		Response Plan
		been approved by a senior Management		3. CSIRT/Incident
		executive.		Response Process
		3. Validate that the incident response plan		4. Provide
		document has been recently (within the last year)		documentation for
		reviewed and the latest plan has been shared with		previously reported
		and communicated to personnel with incident		incidents or alerts.
		response responsibilities.
		4. Verify whether the incident response plans
		covers both IT operational and security
		incidents.
		5. Verify that the incident response plan contains
		the following:
		Roles and responsibilities, and structure and
		organization of the incident response capability;
		Incident response process flows and procedures
		that include steps for preparation, detection and
		analysis, containment, eradication, and recovery;
		Defines reportable incidents and incident
		classification;
		Incident communication and notification;
		Analysis of legal requirements for reporting
		compromises;
		Provides metrics for measuring the incident
		response capability within the organization;
		Defines the resources and management support
		needed to effectively maintain and mature an
		incident response capability;
		System and data recovery;
		Data backup processes.
		6. Verify if the incident response plan is
		periodically updated to address
		system/organizational changes or problems
		encountered or lessons learned during plan
		implementation, execution, training, or testing.
		7. Review documentation from a sample of
		previously reported incidents or alerts to verify
		that the documented incident response plan and
		procedures were followed.
Cyber	Threat		1. Inquire with control owner to determine if the	Inquiry, Inspection,	1. CSIRT Incident
Security	Response	organization develops, documents, and	and/or observation	Response Plan
		disseminate an incident response policy.		2. Security Incident
		2. Examine the incident response plan to		Response Process
		determine if an incident response policy exists		3. Corporate Critical
		and whether the policy address the specific		Incident Process
		purpose, scope, roles and responsibilities,		4. Information
		management commitment, and compliance.		Security Policies
		3. Examine the information security policies and		5. Crisis Management
		procedures (see evidence), CSIRT Incident		Team Plan
		Response Plan, Security Incident Response
		Process, Corporate Critical Incident Process and
		determine if the incident response procedures are
		disseminated to appropriate personnel.
		4. Observe location of incident response plan on
		the organization intranet (or other location) to
		determine how the incident response policies are
		disseminated.
		5. Examine the incident response plan to
		determine if the organization has reviewed and
		updated on an annual basis.
Cyber	Threat		1. Inquired of the control owner to determine	Inquiry, Inspection,	1. Listing of recent
Security	Response	whether security incidents were tracked and	and/or observation	incidents for the
		documented from initiation through closure.		period under review
		2. Obtain a listing of incidents for the period		and parameters/query
		under review and select an appropriate number		used to generate the
		of samples.		report.
		3. Obtain tickets or documentation to validate		2. Documentation of
		that the incidents were documented		incident containment
		(categorized/prioritized), reviewed, tracked and		and mitigation, such
		resolved in a timely manner and includes the		as IT tickets.
		following details:
		The identified solutions or workaround are
		documented, applied and tested, and recovery
		actions are performed to restore the IT-related
		service.
		The satisfactory resolution of incidents and/or
		request fulfillment is verified and is closed.
		4. Determine whether incident thresholds have
		been established and whether the tools have been
		calibrated with the thresholds.
Cyber	Programming		1. Inquire with the control owner to determine	Inquiry, Inspection,	1. Information
Security	Security	whether the organization establishes guidelines	and/or observation	Security Policies
		for the secure development environment for		containing technical
		critical systems.		roles that address
		2. Inspect the information security policies to		development
		determine whether the policies outline guidance		activities, and
		for technical roles and secure development		established guidelines
		environment for critical systems.		for the secure
		3. Validate whether management reviewed the		development
		policy within the past 12 months and		environment for
		communicated it to employees.		critical systems.
		4. Review the secure development standards to		2. Evidence that
		validate whether appropriate measures have been		management reviewed
		described for security of development		the Information
		environments.		Security Policies
		5. Review the access list for a sample of		within the past 12
		development environments and validate whether		months and
		the access has been approved. Also validate		communicated it to
		whether any non-developers have access to the		employees.
		development environment.
Cyber	Programming		1. Inquire with control owner to whether an	Inquiry, Inspection,	1. SDLC policies and
Security	Security	established system development lifecycle	and/or observation	procedures.
		process is in place, documented, maintained, and		2. Evidence that an
		applied for all system and software design,		established system
		acquisition, implementation, configuration,		development lifecycle
		integration, testing, modification, and		process is in place,
		maintenance.		documented,
		2. Obtain and inspect SDLC policies and		maintained.
		procedures to determine whether an established		3. Security
		system development lifecycle process is		requirements for
		documented.		information systems
		3. Verify whether security requirements for		and information
		information systems and information services are		services are identified
		identified as part of SDLC efforts, business
		process re-design, etc.
Cyber	Programming		1. Obtain the SDLC process/methodology	Inquiry, Inspection,	1. Policy for the
Security	Security	documentation and verify whether it specifies	and/or observation	SDLC process
		that the developers should consider information		2. System and
		security during the requirements gathering, high		Services Acquisition
		level design, low level design, development, and		Policies, Procedures
		systems integration phases of developing an		and Standards
		information system.		3. Information
		2. Verify whether the SDLC		Security Procedures
		process/methodology documentation specifies		(SDLC process)
		whether the testing phase should include security
		testing of information systems.
		3. Verify that during the functional requirements
		gathering phase, the information security
		requirements are captured and consider the
		following:
		the level of confidence required towards the
		claimed identity of users, in order to derive user
		authentication requirements
		access provisioning and authorization
		processes
		required protection needs of assets involved
		requirements derived from business processes,
		such as transaction logging and monitoring, non-
		repudiation requirements
		requirements mandated by other security
		controls, e.g., interfaces to logging and
		monitoring or data leakage detection systems
		information users and operators of their duties
		and responsibilities
		4. Verify whether the SDLC
		process/methodology defines the security roles
		and responsibilities during the development
		lifecycle.
		5. Verify whether there is a clear integration
		between the organization risk management
		methodology and SDLC methodology and
		whether it outlines how information systems can
		be classified based on their inherent risk.
Cyber	Programming		1. Inspect if the organization:	Inquiry, Inspection,	1. Security program
Security	Security	Develops a security plan for the information	and/or observation	plans, budget,
		system that:		procedures, and
		Is consistent with the organization's enterprise		policies
		architecture
		2. Information
		Explicitly defines the authorization boundary		Security Governance
		for the system;		Program
		Describes the operational context of the		documentation
		information system in terms of missions and
		business processes;
		Provides the security categorization of the
		information system including supporting
		rationale;
		Describes the operational environment for the
		information system and relationships with or
		connections to other information systems;
		Provides an overview of the security
		requirements for the system;
		Identifies any relevant overlays, if applicable;
		Describes the security controls in place or
		planned for meeting those requirements
		including a rationale for the tailoring decisions;
		and
		Is reviewed and approved by the authorizing
		official or designated representative prior to plan
		implementation;
		Distributes copies of the security plan and
		communicates subsequent changes to the plan to
		organization-defined personnel or roles;
		Reviews the security plan for the information
		system per organization-defined frequency;
		Updates the plan to address changes to the
		information system/environment of operation or
		problems identified during plan implementation
		or security control assessments; and
		Protects the security plan from unauthorized
		disclosure and modification.
		2. Inspect if the organization.
		Identifies organization-defined user actions that
		can be performed on the information system
		without identification or authentication
		consistent with organizational missions/business
		functions; and
		Documents and provides supporting rationale
		in the security plan for the information system,
		user actions not requiring identification or
		authentication.
Cyber	Programming		1. Inquire with control owner/interview	Inquiry, Inspection,	1. Provide written
Security	Security	responsible personnel to understand how	and/or observation	software-development
		production data is sanitized, transferred, and		procedures.
		used for test purposes.		2. Provide a
		2. Obtain and inspect written software-		population of project
		development procedures to verify that		plans/checklists, from
		operational data is sanitized, transferred, when		which a sample will
		used for test purposes.		be selected.
		3. Observe testing processes and interview		3. Provide the project
		personnel to verify operational data is protected		plans and checklists
		through testing.		for the sample
		4. Obtain a population of project plans/checklists		selected.
		for the period under review.		[PCI]
		5. Select a sample of project plans and checklists		1. Provide a
		to determine whether data protection activities		population of data and
		are built into the overall test approach.		accounts from
				production systems
				recently installed or
				updated for the period
				under review, from
				which a sample will
				be selected.
				2. Provide supporting
				evidence for the
				selected sample of
				data and accounts
				from production
				systems.
Cyber	Programming		1. Inquire with the control owner to determine	Inquiry, Inspection,	1. Secure Coding
Security	Security	the following:	and/or observation	Guidelines;
		that documented software and mobile secure		Infrastructure
		coding guidelines are available to outline		Hardening Guidelines
		development and implementation guidance for		and Secure Coding
		software and mobile code		Guidelines.
		that the organization authorizes, monitors, and		2. System and
		controls mobile code use within the information		Communications
		system		Protection Policies
		2. Inspect the Secure Coding Guidelines and		and procedures
		determine that acceptable and unacceptable
		software and mobile coding guidelines along
		with implementation guidance are outlined
		within the documents, including:
		a. Secure coding techniques training is
		required for developers at least annually, based
		on industry best practices and guidance;
		b. Software-development process procedures:
		defines software-development processes
		based on industry standards and leading practices
		defines information security throughout
		the software development lifecycle
		defines that developers must develop
		software applications in accordance with
		standards
		determine that the software-development
		standards are implemented.
		c. Injection flaws:
		Validate inputs to determine that user data
		cannot modify meaning of commands and
		queries.
		Utilizing parameterized queries.
		d. Buffer overflows:
		Validate buffer boundaries.
		Truncating input strings.
		e. Insecure cryptographic storage
		Prevent cryptographic flaws.
		Use strong cryptographic algorithms and
		keys.
		f. Insecure communication
		Determine that insecure communications
		are addressed by coding techniques that properly
		authenticate and encrypt all sensitive
		communications.
		g. Improper error handling
		Validate that improper error handling is
		addressed by coding techniques that do not leak
		information via error messages
		h. All “high risk” vulnerabilities identified in
		the vulnerability identification process
		Verify that coding techniques address any
		“high risk” vulnerabilities that could affect the
		application
		i. Cross-site scripting (XSS)
		Validating all parameters before inclusion
		Utilizing context-sensitive escaping
		j. Improper Access Control
		Proper authentication of users
		Sanitizing input
		Not exposing internal object references to
		users
		User interfaces that do not permit access
		to unauthorized functions.
		k. Cross-site request forgery (CSRF) to
		determine that cross-site request forgery (CSRF)
		is addressed by coding techniques that ensure
		applications do not rely on authorization
		credentials and tokens automatically submitted
		by browsers.
		1. Broken authentication and session
		management:
		Flagging session tokens (for example
		cookies) as “secure”
		Not exposing session IDs in the URL
		Incorporating appropriate time-outs and
		rotation of session IDs after a successful login.
		3. Inspect system and communications protection
		policy and procedures addressing mobile code
		and determine the following:
		that the organization defines the mobile code
		and mobile code technologies that are acceptable
		and unacceptable;
		that the organization establishes restrictions for
		acceptable mobile code and mobile code
		technology use;
		that the organization documents
		implementation guidance for the defined
		acceptable mobile code and code technologies.
		4. Observe the organization's defined processes
		for controlling, authorizing, monitoring, and
		restricting mobile code and determine that the
		organization authorizes, monitors, and controls
		mobile code use within the information system.
Cyber	Programming		1. Inquire with the control owners and determine	Inquiry, Inspection,	1. Policies and
Security	Security	if procedures clearly define that production data	and/or observation	procedures related to
		(live PANs) are not used for testing or		production data (live
		development.		PANs).
		2. Observe the testing processes and determine		2. Population of data
		that the organization's personnel do not use		and accounts from
		production data (live PANs) in testing or in		recently installed or
		development.		updated production
		3. Obtain a population of data and accounts from		systems.
		recently installed or updated production systems.		3. Sample of test data
		4. Select a sample of data and accounts and		and accounts from the
		inspect test data to determine whether production		obtained population.
		data (live PANs) are used for testing or
		development.

In some embodiments, infrastructure layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain infrastructure stack/layer supporting functioning of the underlying hardware, software, servers, databases, networks, interfaces technologies (e.g. APIs etc.).
The sub-risk categories, control and testing objectives, test procedures and request lists for Infrastructure Layer risk category are provided below in Tables 8-10.

TABLE 8

					Risk Level (L,
		Risk	Risk		M, H) (As
Risk Category	Domain	Classification	Number	Risk Description	applicable)

Infrastructure Layer	Servers and	Strategic,	IL-SD1	Lack of guidance and policy of	L, M, H
	Databases	Operational,		functional requirements and
	Configuration	Financial,		migration to production may lead
		Compliance,		to inaccurate Blockchain logic.
		Legal, or
		Reputational
Infrastructure Layer	Servers and	Strategic,	IL-SD2	Lack of an established baseline	L, M, H
	Databases	Operational,		for information technology
	Configuration	Financial,		systems and Blockchain may
		Compliance,		affect operational environments
		Legal, or		and compromise security.
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT1	Unauthorized or untested	L, M, H
		Operational,		changes, or the failure to make
		Financial,		necessary changes to operating
		Compliance,		system, network or application
		Legal, or		configurations or programs
		Reputational		prevent systems from processing
				transaction records completely
				and accurately
Infrastructure Layer	ITGCs	Strategic,	IL-IT2	Lack of segregation for roles	L, M, H
		Operational,		and responsibilities and instance
		Financial,		environments may lead to
		Compliance,		unauthorized changes to
		Legal, or		productions.
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT3	Lack of segregation for roles	L, M, H
		Operational,		and responsibilities and instance
		Financial,		environments may lead to
		Compliance,		unauthorized changes to
		Legal or		productions.
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT4	Transaction records are lost	L, M, H
		Operational,		(e.g. due to system failure)
		Financial,		and data is not recoverable or
		Compliance,		is corrupted/duplicated in the
		Legal, or		recovery process
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT5	Transaction records transferred	L, M, H
		Operational,		between systems are incomplete
		Financial,		or inaccurate.
		Compliance,
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT6	As business processes are	L, M, H
		Operational,		redesigned and modified to reflect
		Financial,		use of Blockchain technology,
		Compliance,		they embed an agreed set of
		Legal, or		appropriate controls
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT7	Application end-users bypass	L, M, H
		Operational,		systems-enforced authorization
		Financial,		and segregation of duties controls
		Compliance,
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT8	Application end-users bypass	L, M, H
		Operational,		systems-enforced authorization
		Financial,		and segregation of duties controls
		Compliance,
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT9	High-risk/powerful accounts	L, M, H
		Operational,		(e.g., super-user, etc.) bypass
		Financial,		systems-enforced authorization
		Compliance,		and segregation of duties
		Legal, or		controls
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT10	Unauthorized access to facilities,	L, M, H
		Operational,		equipment and resources is not
		Financial,		prevented
		Compliance,
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT11	Unauthorized access (by	L, M, H
		Operational,		business users, IT users or
		Financial,		outsiders) to data causes data
		Compliance,		destruction or improper
		Legal, or		amendment of records.
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT12	Unauthorized access (by	L, M, H
		Operational,		business users, IT users or
		Financial,		outsiders) to data causes data
		Compliance,		destruction or improper
		Legal, or		amendment of records.
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT13	Duties are not appropriately	L, M, H
		Operational,		segregated
		Financial,
		Compliance,
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT14	Weak password controls or	L, M, H
		Operational,		security configurations allow
		Financial,		access rights to be circumvented
		Compliance,
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT15	Unauthorized access (by	L, M, H
		Operational,		business users, IT
		Financial,		users or outsiders) to
		Compliance,		Blockchain Operational
		Legal, or		governance tools.
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT16	Unauthorized or untested	L, M, H
		Operational,		changes, or failure to make
		Financial,		necessary changes to scheduled
		Compliance,		job processes prevent systems
		Legal, or		from processing transaction
		Reputational		records completely and
				accurately
Infrastructure Layer	ITGCs	Strategic,	IL-IT17	Unauthorized or untested	L, M, H
		Operational,		changes, or failure to make
		Financial,		necessary changes to scheduled
		Compliance,		job processes prevent systems
		Legal, or		from processing transaction
		Reputational		records completely and
				accurately
Infrastructure Layer	ITGCs	Strategic,	IL-IT18	Blockchain processing errors	L, M, H
		Operational,		are not resolved.
		Financial,
		Compliance,
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT19	Unauthorized access to the	L, M, H
		Operational,		Blockchain technology (i.e.
		Financial,		code configuration tools) is
		Compliance,		prevented.
		Legal, or
		Reputational
Infrastructure Layer	ITGCs	Strategic,	IL-IT20	Management release	L, M, H
		Operational,		management policies and
		Financial,		procedures include processes
		Compliance,		for making emergency
		Legal, or		configuration changes, including
		Reputational		formal review processes for
				all changes categorized as
				emergency.
Infrastructure Layer	ITGCs	Strategic,	IL-IT21	Unauthorized or untested	L, M, H
		Operational,		changes, or failure to make
		Financial,		necessary changes to scheduled
		Compliance,		job processes prevent systems
		Legal, or		from processing transaction
		Reputational		records completely and
				accurately
Infrastructure Layer	Business	Strategic,	IL-BC1	A lack of backups or ineffective	L, M, H
	Continuity and	Operational,		backups may lead to information
	Disaster	Financial,		loss.
	Recovery	Compliance,
		Legal, or
		Reputational
Infrastructure Layer	Business	Strategic,	IL-BC2	Lack of Business Continuity	L, M, H
	Continuity and	Operational,		and Disaster Recovery plans
	Disaster	Financial,		may inhibit the organization's
	Recovery	Compliance,		ability to recover from an outage.
		Legal, or
		Reputational
Infrastructure Layer	Business	Strategic,	IL-BC3	A lack of backups or ineffective	L, M, H
	Continuity and	Operational,		backups may lead to information
	Disaster	Financial,		loss.
	Recovery	Compliance,
		Legal, or
		Reputational
Infrastructure Layer	Business	Strategic,	IL-BC4	Lack of Business Continuity	L, M, H
	Continuity and	Operational,		and Disaster Recovery plans
	Disaster	Financial,		may inhibit the organization's
	Recovery	Compliance,		ability to recover from an
		Legal, or		outage.
		Reputational
Infrastructure Layer	Business	Strategic,	IL-BC5	A lack of Business Continuity	L, M, H
	Continuity and	Operational,		plan and Disaster Recovery plan
	Disaster	Financial,		testing may result in an effective
	Recovery	Compliance,		or failed recovery process.
		Legal, or
		Reputational
Infrastructure Layer	Business	Strategic,	IL-BC6	Lack of communication to key	L, M, H
	Continuity and	Operational,		stakeholders regarding their
	Disaster	Financial,		responsibilities may result in
	Recovery	Compliance,		ineffective recovery activities in
		Legal, or		the event of an outage.
		Reputational
Infrastructure Layer	IT Asset	Strategic,	IL-IT1	Without clearly defined roles	L, M, H
	Management	Operational,		and responsibilities with
		Financial,		Blockchain vendors,
		Compliance,		accountability is lost when
		Legal, or		issues arise within
		Reputational		the relationship
Infrastructure Layer	IT Asset	Strategic,	IL-IT2	Without clearly defined roles	L, M, H
	Management	Operational,		and responsibilities with
		Financial,		Blockchain vendors,
		Compliance,		accountability is lost when
		Legal, or		issues arise within the
		Reputational		relationship
Infrastructure Layer	IT Asset	Strategic,	IL-IT3	Without a comprehensive due	L, M, H
	Management	Operational,		diligence process, vendor risks
		Financial,		may not be completely identified,
		Compliance,		leaving the organization
		Legal, or		susceptible to direct and indirect
		Reputational		risks.
Infrastructure Layer	IT Asset	Strategic,	IT-IL4	Without clearly defined roles	L, M, H
	Management	Operational,		and responsibilities with
		Financial,		Blockchain vendors,
		Compliance,		accountability is lost when
		Legal, or		issues arise within the
		Reputational		relationship
Infrastructure Layer	IT Asset	Strategic,	IL-IT5	Lack of required level of	L, M, H
	Management	Operational,		throughput and performance
		Financial,		can compromise Blockchain
		Compliance,		use cases objectives.
		Legal, or
		Reputational
Infrastructure Layer	IT Asset	Strategic,	IL-IF1	Data exchanged through APIs,	L, M, F
	Management	Operational,		system interfaces may be
		Financial,		intercepted and accessed by
		Compliance,		unauthorized agents within or
		Legal, or		outside the organization's
		Reputational		network

TABLE 9

				In-scope/Out-
				of-Scope
				(TBD-As per
Risk Category	Domain	Control/Test Objective	Control Description	engagement)

Infrastructure	Servers and	References to internal and external	Once the Blockchain has been	In-scope
Layer	Databases	sources (including interaction with	configured, a test plan is
	Configuration	external platforms, systems,	developed to ensure meeting
		networks, and third parties) in the	all functional requirements
		Blockchain logic are accurate.	and approved by the
			Blockchain program
			management. The Blockchain
			configurations are tested by
			the impacted/required
			business and/or the
			Blockchain program
			management team. Test
			exceptions are appropriately
			recorded, monitored and
			tracked for resolution prior to
			migration to production
Infrastructure	Servers and	A baseline configuration of	A configuration management	In-scope
Layer	Databases	information technology systems	program and database exists
	Configuration	and Blockchain is created,	to implement, maintain and
		implemented,	control configuration of
		and maintained	systems and other
			infrastructure elements.
Infrastructure	ITGCs	Change Management controls are	Changes to Blockchain	In-scope
Layer		defined, established, and enforced	Application and Operating
		including proper documentation	System/Network
		and approval	configurations and
			enhancements are adequately
			tested and approved before
			being migrated into
			production and are monitored
			for appropriateness.
Infrastructure	ITGCs	Segregation of Duties is maintained	Access to migrate the	In-scope
Layer		and enforced for any changes, in	Blockchain process
		addition the development, test, and	configurations into production
		production environments are	is restricted to personnel who
		separated.	are independent of the
			configuration team.
			Development, testing, and
			production environments are
			segregated for changes to
			application configurations and
			periodically reviewed to
			ensure access is restricted to
			authorized personnel.
Infrastructure	ITGCs	Segregation of Duties is maintained	Policies are maintained for	In-scope
Layer		and enforced for any changes.	segregation of duties within
			IT
Infrastructure	ITGCs	Backups of information are	Data is appropriately backed	In-scope
Layer		conducted, maintained, and tested	up and recoverable
		periodically.
Infrastructure	ITGCs	Information input and output	Errors in production	In-scope
Layer		checks are performed.	processing are identified and
			resolved
Infrastructure	ITGCs	Change Management controls are	For each new Blockchain	In-scope
Layer		defined, established, and enforced	business process the
		including proper documentation	associated controls are
		and approval,	documented and approved by
			the business and the
			Blockchain program
			management.
Infrastructure	ITGCs	Access permissions are revoked	Terminated employee's/third	In-scope
Layer		based upon access reviews and/or	party or employee's/third
		user terminations.	party access no longer needed
			to Blockchain, database, and
			operating system/network is
			disabled and/or removed in a
			(timely manner).
Infrastructure	ITGCs	Access to systems and assets is	Access requests to the	In-scope
Layer		controlled by incorporating the	application, database, and
		principle of least privilege.	operating system/network are
			properly reviewed and
			authorized by management
Infrastructure	ITGCs	Privileged user roles and	Super-user/administrative	In-scope
Layer		responsibilities are managed and	application, database, and
		tracked.	operating system/network
			transactions or activities and
			sensitive generic IDs are
			monitored
Infrastructure	ITGCs	Physical access controls are in place	Employees', contractors', and	In-scope
Layer		to properly authorize employees,	visitors' access to data
		contractors, and visitors to facilities,	center/facility and the
		equipment and resources,	information system
			components located within the
			facility is provided on a ‘need
			to know’ basis and requires
			organizational approval.
Infrastructure	ITGCs	Physical access to the secure areas	There is physical security in	In-scope
Layer		are monitored.	place over the data center
			from which financially
			significant applications are
			run.
			Key card system is
			implemented in the data
			center for access control. And
			video surveillance is also in
			place to monitor the activities
			in the data center.
			The key card system logs the
			visit to the data center per
			user and ID card.
			If any incident happens, IT
			department will look into the
			system log and video footage
			for investigation.
Infrastructure	ITGCs	Access permissions are reviewed	Data Center Operations	In-scope
Layer		periodically for appropriateness.	performs a semi-annual
			recertification of all users
			with physical access to Data
			Centers
Infrastructure	ITGCs	Segregation of Duties is maintained	Policies and procedures are	In-scope
Layer		and enforced for critical business	maintained for segregation of
		processes and in production	duties within IT
		environments.
Infrastructure	ITGCs	Access to applications, database,	Passwords to applications,	In-scope
Layer		operating system and network is	database/data file, operating
		password protected on a global	system/network, and security
		level and complies with	configurations are set in an
		documented policies or working	effective manner
		practices detailing password
		configurations and configurable
		security parameters.
Infrastructure	ITGCs	Access to the Blockchain	Access to the Blockchain	In-scope
Layer		Operational governance tools is	operational governance tools
		restricted to appropriate personnel.	is recertified by appropriate
			management at regular
			intervals as defined by policy
			guidelines. The approver
			confirms access remains
			commensurate with the
			individual's job
			responsibilities or requests
			changes/revocation to access.
Infrastructure	ITGCs	As changes to the Blockchain are	The Blockchain policies and	In-scope
Layer		contemplated, appropriate controls	procedures on change
		are in place to ensure that they are	approval and propagation
		approved and rolled out across the	across the network are defined
		network in a manner consistent	and include a description of
		with the Blockchain governance	key controls, oversight and
		framework.	escalation procedures.
Infrastructure	ITGCs	As changes to the Blockchain are	Only approved and tested	In-scope
Layer		contemplated, appropriate controls	changes are made to the job
		are in place to ensure that they are	scheduler and rolled out
		approved and rolled out across the	across the network in a
		network in a manner consistent	manner consistent with the
		with the Blockchain governance	Blockchain governance
		framework.	framework.
Infrastructure	ITGCs	Formal policies and procedures	The Blockchain management	In-scope
Layer		have been established to identify	has a documented problem
		the Blockchain processing errors.	management process for the
			Blockchain configurations
			during which errors or
			exceptions are identified,
			tracked, escalated, root causes
			identified and resolved.
Infrastructure	ITGCs	Access permissions are revoked	Access to the Blockchain	In-scope
Layer		based upon access reviews and/or	configuration tools is
		user terminations,	recertified by appropriate
			management at regular
			intervals as defined by policy
			guidelines. The approver
			confirms access remains
			commensurate with the
			individual's job
			responsibilities or requests
			changes/revocation to access.
Infrastructure	ITGCs	Change Management controls are	The formal policies and	In-scope
Layer		defined, established and enforced	procedures include detailed
		including proper documentation	processes and required
		and approval	approvals necessary to make
			an emergency change to the
			Blockchain configuration. A
			formal review is conducted
			for all emergency changes to
			ensure proper protocol and
			SODs were followed.
Infrastructure	ITGCs	Consideration of Blockchain has	Prior to a Blockchain change	In-scope
Layer		been incorporated into ongoing	being placed into production,
		business operations procedures,	operations policies and
		forms and processes.	procedures have been updated
			to include integration with
			Blockchain to ensure the
			business end users are aware
			of the Blockchain impact.
Infrastructure	Business	Upon identified of a processing	Back out plans for Blockchain	In-scope
Layer	Continuity and	error, management enables back	configuration and plan to roll
	Disaster Recovery	out/back up plan including the	over to human processors in
		Blockchain being removed from	case of a Blockchain failure
		production.	are formally documented for
			each Blockchain
			configuration and routinely
			reviewed to ensure still
			complete and accurate
Infrastructure	Business	IT disaster recovery and business	Disaster recovery plan for the	In-scope
Layer	Continuity and	continuity plans have been	Blockchain technology exists
	Disaster Recovery	developed based on the framework	for prolonged outages (with
		and designed to reduce the impact	internal systems or 3rd party
		of a major disruption on the	vendors) and has been tested
		Blockchain functions and processes.	to limit impact business
		The plans are based on risk	operations.
		understanding of potential business
		impacts and address requirements
		for resilience, alternative processing
		and recovery capability of all
		critical IT services including the
		Blockchain use case. The plan is
		tested on a semi-annual basis.
Infrastructure	Business	Backups of information are	The Blockchain configuration	In-scope
Layer	Continuity and	conducted, maintained, and tested	tools and data is included in
	Disaster Recovery	semi-annually	management standard backup
			and recovely plan to ensure
			data is backed up within data
			centers or the cloud and
			available if needed.
Infrastructure	Business	IT disaster recovery and business	Risks to business continuity	In-scope
Layer	Continuity and	continuity plans have been	due to prolonged outages
	Disaster Recovery	developed based on the framework	(with internal systems or with
		and designed to reduce the impact	3rd party vendor) have been
		of a major disruption on the	identified and procedures
		Blockchain Instance functions and	have been formally
		processes. The plans are based on	documented to mitigate any
		risk understanding of potential	risks.
		business impacts and address
		requirements for resilience,
		alternative processing and recovely
		capability of all critical IT services
		including the Blockchain use case.
		The plan is tested on a semi-annual
		basis.
Infrastructure	Business	Business Continuity and Disaster	Business Continuity and	In-scope
Layer	Continuity and	Recovery plans are tested semi-	Disaster Recovery plans are
	Disaster Recovery	annually to validate that the plans	tested semi-annually to verify
		meet the organizational	the validity of established and
		requirements.	implemented information
			security controls and to take
			appropriate corrective actions.
Infrastructure	Business	Recovery activities are	Communication occurs to the	In-scope
Layer	Continuity and	communicated to internal	individuals and teams
	Disaster Recovery	stakeholders and executive and	involved in the recovery plan
		management teams prior to and	to ensure key stakeholders
		during declared outages.	understand their
			responsibilities in the event of
			an outage.
Infrastructure	IT Asset	The Blockchain vendors are	The Blockchain vendors are	In-scope
Layer	Management	monitored for compliance with	monitored on an ongoing
		contractual agreements.	basis to ensure compliance
			with contractual agreements.
Infrastructure	IT Asset	Licensing agreements are	The Blockchain licensing	In-scope
Layer	Management	monitored and renewed as needed.	agreements are reviewed,
			tracked and renewed as
			needed.
Infrastructure	IT Asset	The Blockchain program policies	The Blockchain vendor	In-scope
Layer	Management	and procedures, which includes	selection was based on formal
		formal the Blockchain vendor	selection methodology and
		selection methodology and	detailed business
		standard contract templates and	requirements.
		requirements, are reviewed and
		approved on a periodic basis.
Infrastructure	IT Asset	The Blockchain program policies	The Blockchain vendor	In-scope
Layer	Management	and procedures, which includes	contracts clarifies resource
		The Blockchain contract policies	ownership and hardware
		including clarification of the	procurement requirements for
		Blockchain ownership, are	client and vendor.
		reviewed and approved on a
		periodic basis.

TABLE 10

			Test Type (TBD-
Risk Category	Domain	Test Procedure (#)	As per engagement)	Request List (#)

Infrastructure	Servers and	1. Inquire with the control owners to	Inquiry, Inspection,	1. Policies and procedures
Layer	Databases	determine if the organization	and/or observation	related to configuration
	Configuration	identifies and documents established		settings, specifically regarding
		configuration settings. Review		the test plan of all functional
		existing documentation around test		requirements for configuration.
		exceptions to ensure the test plans		2. Log of test exceptions.
		identifies all functional requirements.
		2. Verify the test exceptions are
		recorded, monitored and tracked for
		resolution prior to migration to
		production
Infrastructure	Servers and	1. Verify whether a configuration	Inquiry, Inspection,	1. Policies, procedures, related
Layer	Databases	management program is documented	and/or observation	to the baseline configuration
	Configuration	and maintained		settings on production
				infrastructures.
Infrastructure	ITGCs		1. Inquire with the control owner and	Inquiry, Inspection,	1. Change Management
Layer		determine that the organization has a	and/or observation	policies, procedures, and
		documented Change Management		standards
		Process and it is reviewed at least		2. Evidence of the last review
		annually and updated as needed.		of documented Change
		2. Obtain a list of changes that were		Management Process.
		migrated to production for the testing		3. Population of changes for
		period.		the applications and systems
		3. Select a sample of changes made to		4. Evidence of change requests
		the production environment and		and approvals
		determine if it was documented,
		tested prior to migration to
		production, and approved by the
		appropriate personnel.
		4. Inspect that appropriate SOD is
		implemented for roles and
		environments.
Infrastructure	ITGCs		1. Inquire with control owners to	Inquiry, Inspection,	1. Screen-prints for each of the
Layer		determine that the development/	and/or observation	following environments:
		testing environments are separate		development
		from the production environment.		testing
		2. Obtain and inspect screen-prints of		production
		the development, testing, and		2. Evidence of access control
		production environment to determine		settings to enforce separation
		that they are in different		between development/testing
		environments.		and production environments.
Infrastructure	ITGCs		1. Determine through interviews with	Inquiry, Inspection,	1. Evidence of segregation of
Layer		control owners whether access	and/or observation	duties in place for each in-
		controls are defined, documented,		scope information system.
		approved and enforced for changes to
		information systems.
Infrastructure	ITGCs		1. Inspect relevant backup	Inquiry, Inspection,	1. Backup policies and
Layer		documentation and inquire with the	and/or observation	procedures
		control to validate whether the		2. Screenshot of backup
		following considerations have been		configuration settings
		determined, documented, and		3. Backup log showing status
		implemented.		of backups
		2. Inspect the backup confirmation		4. Evidence of successful
		settings and frequency to determine		backup restoration
		whether it is in accordance with		5. Reports detailing testing
		policies and procedures.		efforts and the results of the
		3. Review activity logs for backups to		testing efforts
		determine the completeness of the		6. Evidence of backup
		organizations backup efforts.		schedule
		4. Review activity logs for backups to
		determine if an alert is configured to
		notify administrators of successful
		and failed backups.
		5. Review detailing testing efforts and
		the results of the testing efforts.
Infrastructure	ITGCs		1. Inquire with management to	Inquiry, Inspection,	1. Provide the input validation
Layer		determine if the production systems	and/or observation	rules/configuration on the
		and applications have built in		production systems and
		detective alerts if an invalid input is		applications.
		received and an error message is
		generated.
		2. Inspect the input validation rules
		and program logic on the production
		systems and applications to determine
		if input validation checks are
		appropriately configured to validated
		information entered into a data field.
Infrastructure	ITGCs		1. Inquire with control owners to	Inquiry, Inspection,	1. Blockchain use case risk and
Layer		determine the review and approval	and/or observation	control matrix with approval
		process for additional controls from a
		redesign.
		2. Review an updated risk and control
		matrix and inspect for evidence of
		approval
Infrastructure	ITGCs
	1. Inquire with control owners to	Inquiry, Inspection,	1. Information Security Policy
Layer		determine whether the organization	and/or observation	of Access
		revokes user account access in		Provisioning/Deprovisioning
		response to terminations.		Policy
		2. Obtain and inspect policies and		2. Population of total
		procedures to determine the		terminated users
		requirements are clearly stated for the		3. Evidence that access is
		removal of logical access as a result		revoked within the timeframe
		of terminations.		specified by the access control
		3. Select a sample of terminated users		procedures
		and inspect the evidence to determine
		that access is revoked within the
		timeframe specified by the access
		control procedures.
Infrastructure	ITGCs		1. Inquire with control owners to	Inquiry, Inspection,	1. Information Security Policy
Layer		determine the review and approval	and/or observation	of Access
		process for access requests.		Provisioning/Deprovisioning
		2. Obtain the population of access		Policy
		requests and inspect the evidence to		2. User access requests
		determine that access is properly		3. Evidence that access is
		reviewed and approved by		reviewed and approved by
		management.		management
Infrastructure	ITGCs
	1. Inquire with control owners who is	Inquiry, Inspection,	1. Information Security Policy
Layer		responsible for assigning access to	and/or observation	of Access
		verify that access to privileged user		Provisioning/Deprovisioning
		IDs are appropriate and restricted.		Policy
		2. Obtain and inspect documentation		2. Population of users with
		to determine that privileged access		privileged access
		requests are evaluated for		3. Evidence for selected
		appropriateness and follow the		samples, indicating the job
		principles of least privilege.		function(s) or role(s)
		3. Obtain a population of users with		requested, as well as the
		privileged access and select a sample		approval for the access
		of users and inspect evidence to		requested.
		determine the access is necessary and		4. List of privileged user
		approved by the designated authority.		accounts and associated roles.
				5. Access approval matrix
Infrastructure	ITGCs
	1. Inquire with management and	Inquiry, Inspection,	1. Physical access policies and
Layer		inspect the documented process to	and/or observation	procedures
		determine if procedures are defined		2. Populationof new users
		for authorizing and granting physical		3. Access lists to in-scope
		access to employees, contractors, and		facilities and equipment
		visitors based on role or function.
		2. Obtain a population of new users
		who have been granted access to the
		in-scope facilities and equipment.
		3. Select a sample of new users and
		inspect that physical access was
		authorized and documented prior to
		physical access granted.
Infrastructure	ITGCs		1. Inquire with management the key	Inquiry, Inspection,	1. Key card system
Layer		card system implementation process.	and/or observation	implementation policy
		2. Inquire/Observe with management		2. Key card system access list
		that video surveillance is in place at		3. Key card system logs to the
		the data centers.		data centers
		3. Obtain the key card system logs to
		the data centers.
		4. Select a sample of users granted
		access to the data center and inspect
		that key card access was authorized
		and documented prior to physical
		access granted.
Infrastructure	ITGCs		1. Obtain the key card system log to	Inquiry, Inspection,	1. Key card system logs to the
Layer		the data center operations and select a	and/or observation	data center operations
		sample of users to inspect the		2. Evidence of recertifications
		recertification occurs on a semi-		for users with physical access
		annual basis.
Infrastructure	ITGCs		1. Determine through interviews with	Inquiry, Inspection,	1. Evidence of segregation of
Layer		control owners whether access	and/or observation	duties in place for each in-
		controls are defined, documented,		scope information system.
		approved and enforced for changes to
		information systems and critical
		business processes.
Infrastructure	ITGCs		1. Examine the documentation and	Inquiry, Inspection,	1. Screenshots of password
Layer		security parameters to verify they are	and/or observation	configurations
		aligned		2. Password policy
Infrastructure	ITGCs
	1. Inquire with control owner and	Inquiry, Inspection,	1. Information Security Policy
Layer		determine that the organization has a	and/or observation	of Access
		documented recertification policy and		Provisioning/Deprovisioning
		it is reviewed at least annually and		Policy
		updated as necessary.		2. Evidence of recertifications
		2. Select a sample of recertifications		for the Blockchain Operational
		for the Blockchain Operational		governance tools
		governance tools over the testing		3. Evidence of users job
		period and inspect the evidence to		function and role
		determine the appropriate personnel
		confirmed the access and the access
		based on the job function and role is
		appropriate.
Infrastructure	ITGCs		1. Inquire with control owner and	Inquiry, Inspection,	1. Change Management Policy
Layer		determine that the organization has a	and/or observation	inclusive of Blockchain
		documented Blockchain change		policies
		approval policy and procedure and		2. If available, Blockchain
		inspect it includes key controls,		policy
		oversight and escalation procedures.
Infrastructure	ITGCs		1. Inquire with control owner and	Inquiry, Inspection,	1. Blockchain Governance
Layer		determine that the organization has a	and/or observation	Framework
		documented Blockchain governance		2. Evidence of approved
		framework.		changes
		2. Select a sample of approved		3. Job Scheduler
		changes and inspect the appropriate
		personnel approved the change and it
		was tested in accordance with the
		Blockchain governance framework.
Infrastructure	ITGCs		1. Inquire with control owner and	Inquiry, Inspection,	1. Problem Management
Layer		determine that the organization has a	and/or observation	Process for Blockchain
		documented problem management		Configurations
		process for Blockchain		2. Blockchain Configurations
		Configurations.		error or exceptions log
		2. Select a sample of errors or
		exceptions and inspect the evidence
		to ensure they were tracked,
		escalated, root causes identified and
		resolved.
Infrastructure	ITGCs		1. Inquire with control owner and	Inquiry, Inspection,	1. Information Security Policy
Layer		determine that the organization has a	and/or observation	of Access
		documented recertification policy and		Provisioning/Deprovisioning
		it is reviewed at least annually and		Policy
		updated as necessary.		2. Evidence of recertifications
		2. Select a sample of recertifications		for the Blockchain
		for the Blockchain configuration tools		configuration tools
		over the testing period and inspect the		3. Evidence of users job
		evidence to determine the appropriate		function and role
		personnel confirmed the access and
		the access based on the job function
		and role is appropriate.
Infrastructure	ITGCs		1. Inquire with control owner to	Inquiry, Inspection,	1. Change Management
Layer		determine if a Change Management	and/or observation	policies, procedures, and
		policy exists and it is updated as		standards
		needed.		2. Evidence of the last review
		2. Inspect the policy to ensure		of documented Change
		emergency changes to Blockchain		Management Process.
		configuration is included.		3. Population of emergency
		3. Select a sample of emergency		changes for the applications
		changes to Blockchain configurations		and systems
		and inspect the evidence to ensure		4. Evidence of emergency
		policies were followed and the		change and approvals
		appropriate personnel approved the
		change.
Infrastructure	ITGCs		1. Inquire with control owner to	Inquiry, Inspection,	1. Blockchain Operations
Layer		determine if a Blockchain Operations	and/or observation	policy and procedures
		policy exists and it is updated as		2. Evidence of a Blockchain
		needed.		change
		2. Inspect the evidence of a
		Blockchain change to ensure the
		policies and procedures have been
		updated to include the updated
		integration
Infrastructure	Business
	1. Inquire with the control owner to	Inquiry, Inspection,	1. Back out plan
Layer	Continuity	determine if a formal Blockchain	and/or observation	2. Blockchain
	and Disaster	failure plan exists.		failure plan
	Recovery
	2. Obtain the most recent version of		3. Business Continuity plan
		business continuity and disaster
		recovery plans and verify a back out
		plan is included for Blockchain.
Infrastructure	Business		1. Inquire with the control owner to	Inquiry, Inspection,	1. Business Continuity and
Layer	Continuity	determine if a formal business	and/or observation	Disaster Recovery plan
	and Disaster	continuity and disaster recovery		2. Evidence of the organization
	Recovery	management program exists (i.e.,		conducting tests of outages and
		governance, resources, plans)		documenting the results.
		2. Obtain the most recent version of
		business continuity and disaster
		recovery plans and verify whether it
		has been approved by a Senior
		Management executive and includes
		the following:
		Business continuity objectives
		Business processes and critical
		information assets in scope
		Information security continuity
		Business impact analysis
		Recovery objectives and priorities,
		including Recovery Time Objectives
		(RTO) and Recovery Point
		Objectives (RPO)
		Roles and responsibilities
		Dependencies and critical functions
		for delivery of critical services
		3. Inquire with the control owner to
		determine whether the business
		continuity and disaster recovery plans
		have been communicated and shared
		with stakeholders with associated
		responsibilities.
		4. Inquire with control owner to
		determine how often the business
		continuity and disaster recovery plans
		are tested and how they document the
		results of the test.
Infrastructure	Business		1. Verify the standard backup and	Inquiry, Inspection,	1. Standard backup and
Layer	Continuity	recovery plan includes a section	and/or observation	recovery plan
	and Disaster	regarding Blockchain configuration		2. Agreements for the data
	Recovery	tools and data.		center or cloud if applicable
		2. Inspect the agreements with the
		data center or cloud providers to
		determine whether they exist and
		cover the current period.
Infrastructure	Business		1. Inquire with control owner and	Inquiry, Inspection,	1. Business Continuity and
Layer	Continuity	inspect evidence to determine	and/or observation	Disaster Recovery plan
	and Disaster	whether the risks identified and		2. Evidence of risks identified
	Recovery	documented have been mitigated
		within the business continuity and
		disaster recovery plan.
Infrastructure	Business		1. Inquire with control owner and	Inquiry, Inspection,	1. Business continuity and
Layer	Continuity	inspect evidence to determine	and/or observation	disaster recovery plan testing
	and Disaster	whether the business continuity and		report.
	Recovery	disaster recovery plans are tested on a		2. Evidence that corrective
		semi-annually basis, if test results are		actions are taken if necessary.
		reviewed and corrective actions are
		taken if necessary.
Infrastructure	Business		1. Inquire with control owner to	Inquiry, Inspection,	1. Information Security
Layer	Continuity	determine whether communication	and/or observation	policies and procedures
	and Disaster	occurs to the individuals and teams		2. Business Continuity
	Recovery	involved in the recovery processes so		Management Policy
		that key stakeholders understand their		3. Technology Operations
		responsibilities in the event of a		Disaster Recovery Plan
		disaster.
Infrastructure	IT Asset		1. Inspect a sample of vendors and	Inquiry, Inspection,	1. Vendor contracts
Layer	Management	validate that the vendor contracts are	and/or observation	2. Population of vendors
		monitored periodically.
Infrastructure	IT Asset		1. Inspect a sample of vendors and	Inquiry, Inspection,	1. Vendor licensing
Layer	Management	validate that the vendor licensing	and/or observation	agreements
		agreements are monitored		2. Population of vendors
		periodically and renewed as needed.		3. Log of tracking vendor
				licensing agreements
Infrastructure	IT Asset		1. Inquire with the control owner and	Inquiry, Inspection,	1. Vendor management policy
Layer	Management	determine if a vendor management	and/or observation	and procedure
		policy exists.		2. Vendor contracts
		2. Inspect a sample of agreements and		3. Population of new vendors
		validate that the policy and		for the testing period
		procedures were reviewed and
		approved on a periodic basis.
		3. Verify each Blockchain vendor
		includes the standard contract,
		templates and requirements that are
		aligned with the vendor selection
Infrastructure	IT Asset		1. Inquire with the control owner and	Inquiry, Inspection,	1. Vendor management policy
Layer	Management	determine if all relevant information	and/or observation	and procedure
		security requirements are established		2. Vendor contracts
		and agreed with each supplier/vendor		3. Population of new vendors
		that may access, process, store,		for the testing period
		communicate, or provide IT
		infrastructure components for, the
		organizations information.
		2. Inspect a sample of agreements and
		validate they include resource
		ownership, hardware procurement
		requirements, and Blockchain
		ownership.

4.4 Architecture Layer Assessment Work Program

In some embodiments, blockchain architecture layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain architecture stack/layer supporting blockchain permissioned and/or permissioned networks operations and participant lifecycle management.
The sub-risk categories, control and testing objectives, test procedures and request lists for Architecture Layer risk category are provided below in Tables 11-13.

TABLE 11

					Risk Level
		Risk	Risk		(L, M, H)
Risk Category	Domain	Classification	Number	Risk Description	(As applicable)

Architecture Layer	Blockchain	Strategic,	AL-BP1	Lack of an established baseline for	L, M, H
	Platform &	Operational,		Blockchain systems may affect
	Protocol	Financial,		operational environments and
	Configuration	Compliance,		compromise security.
		Legal, or
		Reputational
Architecture Layer	Blockchain	Strategic,	AL-BP2	If hardening standards have not been	L, M, H
	Platform &	Operational,		developed, defined, or implemented.
	Protocol	Financial,		Blockchain systems are unprotected
	Configuration	Compliance,		and vulnerable to malicious attacks.
		Legal, or
		Reputational
Architecture Layer	Blockchain	Strategic,	AL-BP3	Inadequate processes in the design	L, M, H
	Platform &	Operational,		phase of the Blockchain
	Protocol	Financial,		implementation may negatively
	Configuration	Compliance,		impact core system performance.
		Legal, or
		Reputational
Architecture Layer	Blockchain	Strategic,	AL-BP4	Lack of configuration standards	L, M, H
	Platform &	Operational,		and/or lack of adherence to
	Protocol	Financial,		established configuration standards
	Configuration	Compliance,		may lead to failures or inefficiencies
		Legal, or		in the Blockchain production
		Reputational		environment.
Architecture Layer	Blockchain	Strategic,	AL-BP5	Lack of configuration standards	L, M, H
	Platform &	Operational,		and/or lack of adherence to
	Protocol	Financial,		established configuration standards
	Configuration	Compliance,		may lead to failures or inefficiencies
		Legal, or		in the Blockchain production
		Reputational		environment.
Architecture Layer	Blockchain	Strategic,	AL-BP7	Insufficient test plans lead to the	L, M, H
	Platform &	Operational,		inability to meet the requirements
	Protocol	Financial,		identified in the analysis and design
	Configuration	Compliance,		phase.
		Legal, or
		Reputational
Architecture Layer	Blockchain	Strategic,	AL-BP8	Insufficient test plans lead to the	L, M, H
	Platform &	Operational,		inability to meet the requirements
	Protocol	Financial,		identified in the analysis and design
	Configuration	Compliance,		phase.
		Legal, or
		Reputational
Architecture Layer	Hardware Security	Strategic,	AL-BP9	HSM devices are properly	L, M, H
	Modules	Operational,		configured and maintained
		Financial,		which may expose the Blockchain use case
		Compliance,		supporting systems or sensitive data
		Legal, or		to unauthorized parties.
		Reputational
Architecture Layer	Signature	Strategic,	AL-SM1	Lack of effective cryptographic keys	L, M, H
	Management	Operational,		management may expose the keys to
		Financial,		potential modification, loss,
		Compliance,		destruction or disclosure to
		Legal, or		unauthorized parties.
		Reputational
Architecture Layer	Signature	Strategic,	AL-SM2	Lack of effective cryptographic keys	L, M, H
	Management	Operational,		management may expose the keys to
		Financial,		potential modification, loss,
		Compliance,		destruction or disclosure to
		Legal, or		unauthorized parties.
		Reputational
Architecture Layer	Signature	Strategic,	AL-SM3	Lack of effective cryptographic keys	L, M, H
	Management	Operational,		management may expose the keys to
		Financial,		potential modification, loss,
		Compliance,		destruction or disclosure to
		Legal, or		unauthorized parties.
		Reputational
Architecture Layer	Signature	Strategic,	AL-SM4	Lack of effective cryptographic keys	L, M, H
	Management	Operational,		management may expose the keys to
		Financial,		potential modification, loss,
		Compliance,		destruction or disclosure to
		Legal, or		unauthorized parties.
		Reputational
Architecture Layer	Cryptography	Strategic,	AL-C1	Inadequate protection of information	L, M, H
		Operational,		in Blockchain systems through
		Financial,		cryptographic techniques and
		Compliance,		effective key management may
		Legal, or		result in the potential compromise of
		Reputational		confidentiality or integrity of
				information in transmission
				or storage.
Architecture Layer	Cryptography	Strategic,	AL-C2	Inadequate protection of information	L, M, H
		Operational,		in Blockchain systems through
		Financial,		cryptographic techniques and
		Compliance,		effective key management may
		Legal, or		result in the potential compromise of
		Reputational		confidentiality or integrity of
				information in transmission
				or storage.
Architecture Layer	Cryptography	Strategic,	AL-C3	Inadequate protection of information	L, M, H
		Operational,		in Blockchain systems through
		Financial,		cryptographic techniques and
		Compliance,		effective key management may
		Legal, or		result in the potential compromise of
		Reputational		confidentiality or integrity of
				information in transmission
				or storage.
Architecture Layer	Cryptography	Strategic,	AL-C4	Inadequate protection of information	L, M, H
		Operational,		in Blockchain systems through
		Financial,		cryptographic techniques and
		Compliance,		effective key management may
		Legal, or		result in the potential compromise of
		Reputational		confidentiality or integrity of
				information in transmission
				or storage.
Architecture Layer	Cryptography	Strategic,	AL-C5	Lack of compliance may result in	L, M, H
		Operational,		ineffective controls thereby
		Financial,		heightening organization′s security
		Compliance,		and compliance risks.
		Legal, or
		Reputational
Architecture Layer	Scalability /Capacity	Strategic,	AL-SC1	System capacity is not monitored	L, M, H
	Management	Operational,		which may lead to interruption
		Financial,		and/or failure to key systems.
		Compliance,
		Legal, or
		Reputational
Architecture Layer	Scalability/Capacity	Strategic,	AL-SC2	Inadequate procedures to monitor	L, M, H
	Management	Operational,		the capacity and performance of IT
		Financial,		resources may lead to delivery
		Compliance,		failure of service performance
		Legal, or		agreements.
		Reputational
Architecture Layer	Scalability/Capacity	Strategic,	AL-SC3	Failure to define, agree, record and	L, M, H
	Management	Operational,		manage the levels of service as
		Financial,		required by the business may result
		Compliance,		in the agreed service continuity and
		Legal, or		availability commitment to
		Reputational		customers not being met in all
				circumstances.
Architecture Layer	Availability	Strategic,	AL-A1	Lack of redundant information	L, M, H
		Operational,		processing facilities may lead to
		Financial,		disruption of critical services in the
		Compliance,		event Blockchain information
		Legal, or		processing facilities are unavailable
		Reputational		due to excess capacity or other
				threats.
Architecture Layer	Encryption (EN)	Strategic,	AL-EN01	Privileged access is not	L, M, H
		Operational,		appropriately restricted, logged, and
		Financial,		monitored for unencrypted data,
		Compliance,		which can lead to unauthorized
		Legal, or		access
		Reputational
Architecture Layer	Encryption (EN)	Strategic,	AL-EN02	Data in transit is not secure and may	L, M, H
		Operational,		be compromised or accessed by
		Financial,		unauthorized participants,
		Compliance,		compromising the integrity of the
		Legal, or		data
		Reputational
Architecture Layer	Encryption (EN)	Strategic,	AL-EN03	Data at rest or in storage is not	L, M, H
		Operational,		secure and may be accessible by
		Financial,		unauthorized participants,
		Compliance,		compromising the integrity of the
		Legal, or		data
		Reputational
Architecture Layer	Encryption (EN)	Strategic,	AL-EN04	Databases lack encryption to protect	L, M, H
		Operational,		and recover data in the case of loss
		Financial,		or theft
		Compliance,
		Legal, or
		Reputational
Architecture Layer	Encryption (EN)	Strategic,	AL-EN05	Data is not retained for DLT inputs.	L, M, H
		Operational,		PKIs, or other critical systems; lack
		Financial,		of availability limits backup and
		Compliance,		recovery capability
		Legal, or
		Reputational
Architecture Layer	Encryption (EN)	Strategic,	AL-EN06	PKI Certificate Authority (CA) is	L, M, H
		Operational,		insufficiently isolated from tire rest
		Financial,		of the network
		Compliance,
		Legal, or
		Reputational
Architecture Layer	Encryption (EN)	Strategic,	AL-EN07	No PKI Certificate Authority (CA)	L, M, H
		Operational,		is present in the organization′s
		Financial,		network to validate data
		Compliance,		transmission or transactions on the
		Legal, or		blockchain
		Reputational
Architecture Layer	Key Management	Strategic,	AL-EN07	Lack of proper physical and logical	L, M, H
		Operational,		custody of the keys (private and
		Financial,		public) can compromise a single or
		Compliance,		multiple users on the Blockchain.
		Legal, or
		Reputational
Architecture Layer	Data Retention	Strategic,	AL-DR01	Data is not retained for DLT inputs,	L, M, H
	(DR)	Operational,		PKIs, or other critical systems; lack
		Financial,		of availability limits backup and
		Compliance,		recovery capability
		Legal, or
		Reputational
Architecture Layer	Consensus (CS)	Strategic,	TL-CS01	No formal consensus protocol is	L, M, H
		Operational,		established, system validators for
		Financial,		DLT entries lacks authentication
		Compliance,
		Legal, or
		Reputational
Architecture Layer	Consensus (CS)	Strategic,	AL-CS02	Implementation processes for	L, M, H
		Operational,		system coding related to consensus
		Financial,		have not been defined: no formal
		Compliance,		channel for change management
		Legal, or		exists
		Reputational
Architecture Layer	Consensus (CS)	Strategic,	AL-CS03	System development and	L, M, H
		Operational,		management life cycle does not
		Financial,		exist or does not apply to
		Compliance,		consensus system architecture
		Legal, or
		Reputational
Architecture Layer	Consensus (CS)	Strategic,	AL-CS04	The organization has no approvals	L, M, H
		Operational,		process for change management
		Financial,		affecting consensus or docs not
		Compliance,		secure against improper approvals
		Legal, or		being issued
		Reputational
Architecture Layer	Consensus (CS)	Strategic,	AL-CS05	There is no access review or audit	L, M, H
		Operational,		mechanism for the consensus
		Financial,		protocol or any users, systems, or
		Compliance,		participants affiliated with DLT
		Legal, or		validation
		Reputational
Architecture Layer	Consensus (CS)	Strategic,	AL-BC1	Consensus mechanisms	L, M, H
		Operational,		implemented do not provide comfort
		Financial,		on the immutability of the data
		Compliance,		stored on the Blockchain.
		Legal, or
		Reputational
Architecture Layer	Consensus (CS)	Strategic,	AL-BC2	Consensus mechanisms	L, M, H
		Operational,		implemented do not provide comfort
		Financial,		on the immutability of the data
		Compliance,		stored on the Blockchain.
		Legal, or
		Reputational

TABLE 12

				In-scope/Out-
Risk				of-Scope (TBD-
Category	Domain	Control/Test Objective	Control Description	As per engagement)

Architecture	Blockchain Platform &	The organization has created	A configuration management	In-scope
Layer	Protocol Configuration	a configuration management	program and database exists to
		database (CMDB) that	implement, maintain and control
		houses all Blockchain	configuration of Blockchain
		systems and infrastructure.	systems and oilier infrastructure
		A baseline configuration of	elements (including hardware,
		the Blockchain system is	software, firmware, and
		created, implemented, and	documentation). The program
		maintained.	requires the identification of
			baseline configurations (original
			versions) of Blockchain
			infrastructure elements (hardware,
			software etc.). A central repository
			of configuration items (Cl), their
			attributes, and their inter-linkages
			is established and maintained. CIs
			are linked to the services that they
			support. Current and prior
			configuration for all CIs, including
			Blockchain production servers,
			network devices, and databases is
			captured and maintained in the
			central repositon. in order to
			support rollback
Architecture	Blockchain Platform &	Blockchain systems	Blockchain system configuration	In-scope
Layer	Protocol Configuration	hardening standards arc	and hardening standards arc
		established and maintained.	developed, communicated,
		Blockchain system	implemented and maintained. The
		configuration and hardening	standards followed address all
		standards are consistent	known security vulnerabilities and
		with industry-accepted	are consistent with industry-
		standards, vendor specific	accepted system hardening
		guidelines and address all	standards and any vendor specific
		known security	guidelines
		vulnerabilities
Architecture	Blockchain Platform &	The Blockchain Instance	The Blockchain Instance process	In-scope
Layer	Protocol Configuration	impact on core processing	impact on core system
		system performance has	performance is documented and
		been determined and	approved by IT and the
		appropriately addressed as	Blockchain Instance program
		part of functional	management.
		specification process
Architecture	Blockchain Platform &	Newly implemented the	Once the Blockchain Instance has	In-scope
Layer	Protocol Configuration	Blockchain Instances are	been configured, a test plan is
		configured to completely or	developed to ensure meeting all
		accurately process data.	functional requirements and
		The Blockchain Instances	approved by the Blockchain
		are configured to effectively	Instance program management.
		meet the business	The Blockchain Instance
		requirements.	configurations are tested by the
			impacted/required business and/or
			the Blockchain Instance program
			management team. Test
			exceptions are appropriately
			recorded, monitored and tracked
			for resolution prior to migration to
			production.
Architecture	Blockchain Platform &	Auditability of the	The audit logging of the	In-scope
Layer	Protocol Configuration	Blockchain Instance	Blockchain Instance software tool
		processing has been enabled	has been enabled. The ability to
		within the tool.	change the audit capacities is
			restricted to authorized personnel
			outside of the configuration
			function.
Architecture	Blockchain Platform &	Testing architecture and	Once the Blockchain Instance has	In-scope
Layer	Protocol Configuration	requirements have been	been configured, a test plan is
		defined and documented.	developed to ensure meeting all
		Test plan including test	functional requirements and
		cases and procedures are	approved by the Blockchain
		formally defined.	Instance program management.
			The Blockchain Instance
			configurations are tested by the
			impacted/required business and/or
			the Blockchain Instance program
			management team. Test
			exceptions are appropriately
			recorded, monitored and tracked
			for resolution prior to migration to
			production.
Architecture	Blockchain Platform &	Technical test environments	The Blockchain Instance	In-scope
Layer	Protocol Configuration	are stable and managed	configuration testing take place in
		properly.	environments which are logically
			segregated from and mirror the
			legacy system production
			environment.
Architecture	Hardware Security	HSM devices are properly	HSM devices are deployed,	In-scope
Layer	modules	configured and maintained	properly configured and
		which may expose the	maintained to prevent the
		Blockchain use case	Blockchain use case supporting
		supporting systems or	systems or sensitive data exposure
		sensitive data to	to unauthorized parties
		unauthorized parties
Architecture	Signature Management	The integrity of the	A formal key management system	In-scope
Layer		Blockchain cryptosystem is	and associated processes exist to
		maintained through the	securely manage (i.e.. generate,
		proper management of	distribute, store, access, backup
		encryption keys. Public and	and destroy) secret/private keys
		private keys are securely	and public keys issued by trusted
		managed through formal	Certification Authorities. Formal
		management processes.	procedures are in place to protect
			keys used to secure stored
			cardholder data against disclosure
			and misuse. Public key certificates
			are issued per defined standards or
			from an approved service
			provider.
Architecture	Signature Management	The integrity of the	1. Examine user access lists to	In-scope
Layer		Blockchain cryptosystem is	verify that access to keys is
		maintained through the	restricted to the fewest number of
		proper management of	custodians necessary
		encryption keys.	2. Verify whether equipment used
		Cryptographic key access	to generate, store, and archive
		and storage is restricted and	keys are protected.
		controlled.
Architecture	Signature Management	The integrity of the	Cryptographic keys are stored in	In-scope
Layer		Blockchain cryptosystem is	the fewest locations possible.
		maintained through the	Secret mid private keys used to
		proper management of	encrypt/decrypt cardholder data
		encryption keys.	are stored in one (or more) of the
		Cryptographic keys arc	following forms at all times:
		securely stored.	Encrypted with a key-encrypting
		The integrity of the	key that is at least as strong as the
		Blockchain cryptosystem is	data-encrypting key, and that is
		maintained through the	stored separately from the data-
		proper management of	encrypting key
		encryption keys.	Within a secure cryptographic
			device (such as a hardware (host)
			security module (HSM) or PTS-
			approved point-of-interaction
			device)
			As at least two full-length key
			components or key shares, in
			accordance with an industry-
			accepted method
Architecture	Signature Management	The integrity of the	Cryptographic keys are changed at	In-scope
Layer		Blockchain cryptosystem is	the end of their cryptoperiod. as
		maintained through the	defined by the associated
		proper management of	application vendor or key owner,
		encryption keys.	and based on industry best
		Cryptographic key change	practices and guidelines. Keys arc
		management is followed in	retired or replaced (for example,
		accordance with best	archiving, destruction, and/or
		practices and guidelines.	revocation) as deemed necessary
			when the integrity of the key has
			been weakened (for example,
			departure of an employee with
			knowledge of a clear-text key
			component), or keys are suspected
			of being compromised.
Architecture	Cryptography	Control: Stored classified	Classified data (e.g.. CUI, PHI.	In-scope
Layer		data are encrypted and	CHD. PII) is stored in an
		access controlled.	encrypted format regardless of the
		Control Objective: Data-at-	medium (including mobile
		rest is protected through	devices). Access to the encryption
		cryptographic techniques.	keys is restricted to authorized
			personnel.
Architecture	Cryptography	Data-at-rest is protected	Logical access for disk encryption	In-scope
Layer		through cryptographic	is managed separately and
		techniques. Disk encryption	independently of native operating
		managed independently of	system authentication.
		the native operating system
		authentication.
Architecture	Cryptography	Data-in-transit is protected	Cryptographic techniques are used	In-scope
Layer		through cryptographic	to protect the confidentiality and
		techniques. Data integrity in	integrity of data in transmission.
		transmission protected with	While transmitting cardholder
		secure cryptography.	data, the following measures are
			implemented:
			Only trusted keys and certificates
			are accepted.
			The protocol in use only supports
			secure versions or configurations.
			The encryption strength is
			appropriate for the encryption
			methodology in use.
Architecture	Cryptography	Data-in-transit is protected	Secure messaging utilities and	In-scope
Layer		through cryptographic	facilities are used to protect data in
		techniques. Data is	transmission. Electronic
		protected in transmission	messaging such as MQ Series,
		through secure messaging	middleware, system to system
		utilities and facilities.	application calls, batch processing,
			email. Electronic Data Interchange
			(EDI), and instant messaging, has
			security provisions in place to
			protect messages from
			unauthorized access, modification,
			and denial of service.
Architecture	Cryptography	Cryptographic controls	Cryptographic controls are used in	In-scope
Layer		comply with relevant	compliance with all relevant
		agreements, legislation, and	agreements, legislation, and
		regulations. Cryptographic	regulations. FIPS-validated
		controls have been	cryptography is leveraged to
		established to comply with	protect the confidentiality of CUI.
		all business relevant	If cryptography is required based
		agreements, legislation, and	on the selection of other security
		regulations.	controls, each type of
			cryptography required is clearly
			defined.
Architecture	Cryptography	System capacity is	Real time monitoring of system	In-scope
Layer		monitored in real time to	capacity is performed to enable the
		meet availability	implementation of additional
		requirements. System	capacity to help meet availability
		capacity is monitored for	commitments and requirements,
		operations regarding	and reports are made available for
		information processing	management review.
		facilities
Architecture	Scalabiltiy/Capacity	Adequate capacity is	Availability requirements are	In-scope
Layer	Management	maintained to prevent	agreed upon with customers.
		interruptions. System	Availability, capacity, and
		capacity is adequately	performance baselines have been
		monitored to ensure system	established based on customer
		availability is maintained.	needs, business impact analysis,
			organizational policies etc.
			Adequate capacity, performance,
			and availability is maintained to
			prevent business disruptions, and
			to meet existing and changing
			business needs.
Architecture	Scalabiltiy/Capacity	Baselines are monitored for	Deviations from established	In-scope
Layer	Management	deviations and are resolved	availability, performance, and
		or followed up. Maintain	capacity baselines are monitored,
		service availability, efficient	reported, and resolved. After
		management of resources,	monitoring, measuring, analyzing,
		and optimization of system	reporting, and reviewing
		performance through	availability, performance, and
		prediction of future	capacity deviations from
		performance and capacity	established baselines, all
		requirements.	outstanding issues are followed
			up.
Architecture	Availability	Blockchain production	Blockchain production systems	In-scope
Layer		system availability is	are monitored for availability and
		monitored and incidents are	any incidents are documented in a
		documented. Technical	ticketing system.
		capabilities exist to enable
		resiliency of Blockchain
		information processing
		facilities in accordance with
		availability objectives in the
		event of disruption.

TABLE 13

			Test Type
Risk			(TBD-As per
Category	Domain	Test Procedure (#)	engagement)	Request List (#)

Architecture	Blockchain		1. Inquire with the control owner to	Inquiry,	1. Policies, procedures,
Layer	Platform &	determine whether a configuration	Inspection, and/or	related to the Blockchain
	Protocol	management database (CMDB) that	observation	baseline configuration
	Configuration	includes Blockchain configuration		settings on production
		items (Cl) is maintained.		infrastructures.
		2. Verify whether a configuration		2. Enterprise Blockchain
		management plan is documented and		production infrastructure
		maintained and includes the following:		configuration management
		Roles and responsibilities		plan.
		Process for identifying and managing
		CIs
		Definitions of CI
		Interlinkages between CIs
		3. Inspect the CMBD and determine for
		a sample of systems, where the
		Blockchain baseline configuration is
		maintained. Also, validate whether
		previous versions of the CIs and
		corresponding documentation is
		archived and maintained to support
		rollback.
		4. Verify whether the CMDB is
		reviewed for accuracy and consistency
		on a periodic basis. Verify whether the
		organization reviews and updates the
		baseline configuration of the
		Blockchain system on a periodic basis
		or upon any upgrades or installations.
Architecture	Blockchain		1. Inquire with control owner to	Inquiry,	1. Provide evidence of the
Layer	Platform &	determine if the organization:	Inspection, and/or	organization′s documented
	Protocol	Establishes and documents	observation	change management
	Configuration	configuration settings for Blockchain		methodology for the
		technology products employed within		production environment.
		the information system using the		2. Provide evidence of
		appropriate security configuration		Blockchain Network
		baseline that reflect the most restrictive		Hardening Guidelines.
		mode consistent with operational		Production Network
		requirements:		Security Standard, and
		Implements the configuration settings;		Change Management
		2. Inquire of the control owner and		methodology.
		determine the Blockchain system		3. Change Management
		configuration standards are consistent		methodology
		with industry-accepted configuration		4. Production Network
		and hardening standards and are applied		Security Standard.
		when new systems are configured and		5. Blockchain
		verified as being in place before a		Infrastructure Hardening
		Blockchain system is installed on the		Guidelines.
		network.
		3. Inspect the Network Hardening
		Guidelines. Production Network
		Security Standard, and Change
		Management methodology and
		determine if the organization has
		documented and implemented a change
		management methodology for the
		production environment to govern the
		Blockchain configuration management
		process.
Architecture	Blockchain		1. Inquire with control owner to	Inquiry,	1. SDLC policies and
Layer	Platform &	whether an established system	Inspection, and/or	procedures.
	Protocol	development lifecycle process is in	observation	2. Evidence that an
	Configuration	place, documented, maintained, and		established system
		applied for all Blockchain system and		development lifecycle
		software design, acquisition,		process is in place,
		implementation, configuration,		documented, maintained
		integration, testing, modification, and		for the development or
		maintenance.		installation of Blockchain
		2. Obtain and inspect SDLC policies		systems.
		and procedures to determine whether mi		3. Performance
		established Blockchain system		requirements for
		development lifecycle process is		Blockchain information
		documented.		systems and information
		3. Verify whether an impact assessment		services are identified.
		and performance requirements for
		Blockchain information systems and
		information services are identified as
		part of SDLC efforts, business process
		re-design, etc.
Architecture	Blockchain		1. Obtain Blockchain systems	Inquiry,	1. Obtain Blockchain
Layer	Platform &	configurations.	Inspection, and/or	systems configurations.
	Protocol	2. Assess configuration relative to	observation
	Configuration	functional requirements.
Architecture	Blockchain		1. Obtain Blockchain systems	Inquiry,	1. Obtain Blockchain
Layer	Platform &	configurations.	Inspection, and/or	systems configurations.
	Protocol	2. Assess Audit logging capabilities in	observation
	Configuration	the Blockchain system relative to
		internal guidelines and leading
		practices.
Architecture	Blockchain		1. Obtain Blockchain systems test plans	Inquiry,	1. Obtain Blockchain
Layer	Platform &	and requirements.	Inspection, and/or	systems executed test plans
	Protocol
	2. Determine if the test plans are	observation	and requirements.
	Configuration	executed as per requirements.
Architecture	Blockchain		1. Obtain information including version	Inquiry,	1. Obtain information
Layer	Platform &	numbers of the test and production	Inspection, and/or	including version numbers
	Protocol	environments for Blockchain systems.	observation	of the test and production
	Configuration
	2. Determine if the testing takes place in		environments for
		environments which are logically		Blockchain systems.
		segregated from and mirror the legacy
		system production environment.
Architecture	Hardware Security	Determine if HSM device(s) are	Inquiry,	1. Obtain HSM information
Layer	Modules	deployed, properly configured and	Inspection, and/or	including vendor,
		maintained to prevent the Blockchain	observation	configuration and leading
		use case supporting systems or sensitive		practices guidelines.
		data exposure to unauthorized parties.
Architecture	Signature		1. Review key management procedures	Inquiry,	1. Encryption and Key
Layer	Management	and determine if they address secure	Inspection, and/or	Management policies and
		generation, distribution, storage,	observation	procedures.
		backup, and access management of		2. User access list of
		keys.		cryptographic key
		2. Review key management standards to		custodians.
		determine key strength aligns with		3. Information Security
		industry leading standards.		policies and procedures
		3. Determine through interview with		4. Security Incident
		control owner that formal roles and		Response Process
		responsibilities have been established		5. Audit and
		for management keys.		accountability policies.
		4. Examine key-management policies		6. Procedures addressing
		and procedures to verify processes arc		non-repudiation.
		specified to protect keys against		7. Automated mechanisms
		disclosure and misuse and include at		configured with non-
		least the following:		repudiation capabilities.
		Access to keys is restricted to the
		fewest number of custodians necessary.
		Key-encrypting keys are at least as
		strong as the data encrypting keys they
		protect.
		Key-encrypting keys are stored
		separately from data encrypting keys.
		Keys are stored securely in the fewest
		possible locations and forms.
		5. Verify that key-management
		procedures specify how to generate
		strong keys.
		6. Observe the method for generating
		keys to verify that strong keys are
		generated.
		7. Observe the method for distributing
		keys to verify that keys are distributed
		securely.
		8. Observe the method for storing keys
		to verify that keys are stored securely.
Architecture	Signature		1. Inquire about Key Management	Inquiry,	1. Obtain Key Management
Layer	Management	process.	Inspection, and/or	policies and procedure
		2. Review the key Management process	observation		2. Test approval, SOD and
		and determine if appropriate level of		ownership activities for
		approval, SOD, and ownership		Key Management
		mechanisms are in place.
		3. Test approval. SOD. and ownership
		mechanisms to determine if the Key
		Management process is safe, secure and
		docs not lack required level of integrity.
Architecture	Signature		1. Examine key storage locations and	Inquiry,	1. Identify and assess key
Layer	Management	observe processes to verify that keys are	Inspection, and/or	storage locations,
		stored in the fewest possible locations.	observation	documented procedures,
		2. Examine documented procedures to		system configurations.
		verify that cryptographic keys used to
		encrypt/decrypt cardholder data must
		only exist in one (or more) of the
		following forms at all times.
		Encrypted with a key-encrypting key
		that is at least as strong as the data-
		encrypting key, and that is stored
		separately from the data-encrypting key
		Within a secure cryptographic device
		(such as a hardware (host) security
		module (HSM) or PTS-approved point-
		of-interaction device)
		As key components or key shares, in
		accordance with an industry-accepted
		method
		3. Examine system configurations and
		key storage locations to verify that
		cryptographic keys used to
		encrypt/decrypt cardholder data exist in
		one (or more) of the following form at
		all times.
		Encrypted with a key-encrypting key
		Within a secure cryptographic device
		(such as a hardware (host) security
		module (HSM) or PTS-approved point-
		of-interaction device)
		As key components or key shares, in
		accordance with an industry-accepted
		method
		4. Wherever key-encrypting keys are
		used, examine system configurations
		and key storage locations to verify:
		Key-encrypting keys are at least as
		strong as the data-encrypting keys they
		protect
		Key-encrypting keys are stored
		separately from data-encrypting keys.
Architecture	Signature		1. Verify that key-management	Inquiry,	1. Identify and assess
Layer	Management	procedures include a defined crypto	Inspection, and/or	encryption mechanism for
		period for each key type in use and	observation	Key Management
		define a process for key changes at the
		end of the defined cryptoperiod (s) (
		(for example, after a defined period of
		time has passed and/or after a certain
		amount of cipher-text has been
		produced by a given key)
		2. Interview personnel to verify that
		keys are changed at the end of the
		defined cryptoperiod(s).
		3. Verify that key-management
		procedures specify processes for the
		following:
		The retirement or replacement of keys
		when tire integrity of the key has been
		weakened
		The replacement of known or
		suspected compromised keys.
		Any keys retained after retiring or
		replacing are not used for encryption
		operations
		4. Interview personnel to verify the
		following processes are implemented:
		Keys are retired or replaced as
		necessary when the integrity of the key
		has been weakened, including when
		someone with knowledge of the key
		leaves the company.
		Keys are replaced if known or
		suspected to be compromised.
		Any keys retained after retiring or
		replacing are not used for encryption
		operations.
Architecture	Cryptography		1. Inquire with the control owner to	Inquiry,	1. Information Security
Layer		determine how classified data is	Inspection, and/or	Policies.
		encrypted at rest in all formats	observation		2. Data Classification
		(databases, media, mobile devices,		Policy
		removable storage, etc.) and how access		3. Information Security
		to the encryption keys is restricted to		Policy for encryption
		authorized personnel in accordance with		requirements.
		encryption requirements. For data at		4. System generated list of
		rest, assess whether one of the		individuals with access to
		following is implemented:		the encryption keys with
		Full disk encryption:		names and respective job
		Partial encryption where the access		title.
		control will only allow writing to the		5. Configuration or
		encrypted partition.		evidence showing systems
		2. Obtain and inspect the cryptographic		components/backups are
		controls policy to determine whether it		encrypted using AES-256
		aligns to industry standards.		via FIPS 140-2 validated
		3. Obtain a system generated list of		encryption
		individuals with access to the		6. Evidence indicating the
		encryption keys and determine whether		use of either full disk
		access is restricted to the authorized		encryption, or partial
		personnel.		encryption with access
		4. Inspect that only approved hard drive		controls to allow writing to
		encryption software has been deployed		the encrypted partition
		to mobile devices and systems that hold
		sensitive data.
Architecture	Cryptography		1. Inquire with the control owner to	Inquiry,	1. Provide the policies and
Layer		determine if disk encryption is used	Inspection, and/or	procedures related to
		(rather than file or column-level	observation	access management.
		database encryption).		2. Provide the
		2. Inspect policies and procedures and		configurations for the in
		the configurations for the in scope		scope systems validating
		systems to ensure that logical access is		that logical access is
		managed separately and independently		managed separately and
		of native operating system		independently of native
		authentication and access control		operating system
		mechanisms (for example, by not using		authentication and access
		local user account databases or general		control mechanisms.
		network login credentials).		3. Evidence that decryption
		3. Validate that decryption keys are not		keys are not associated
		associated with user accounts.		with user accounts.
Architecture	Cryptography		1. Inquire with control owners to	Inquiry,	1. Information Security
Layer		determine that sensitive data is	Inspection, and/or	Policies and procedures
		encrypted while being exchanged	observation	related to Encryption.
		between systems within the network		2. Screenshots of the
		and also when transmitted over public		applicable encryption or
		networks.		network protection utility.
		2. Identify all locations where sensitive		3. TLS implementation
		data is transmitted or received over		system configurations.
		open, public networks. Examine		4. Security
		documented standards and compare to		Implementation Guide.
		system configurations to verify the use
		of security protocols and strong
		cryptography for all locations.
		3. Select and observe a sample of
		inbound and outbound transmissions as
		they occur (for example, by observing
		system processes or network traffic) to
		verify that all sensitive data is encrypted
		with strong cryptography during transit.
Architecture	Cryptography		1. Inspect if the organization ensures	Inquiry,	1. Evidence that secure
Layer		that the transmission, movement, and	Inspection, and/or	messaging utilities and
		removal of information is restricted to	observation	facilities are used to protect
		authorized users and processes, and is		data in transmission.
		protected. Thus enabling the entity to		2. Policies and procedures
		meet its commitments and requirements		related to the protection of
		as they relate to security. availability,		data-in-transit.
		processing integrity, or confidentiality
		or any combination thereof.
		2. For the electronic messaging systems,
		provide screenshots and/or
		documentation that controls have been
		implemented to address the following :
		protecting messages from unauthorized
		access, modification or denial of
		service, ensuring correct addressing and
		transportation of the message, general
		reliability and availability of the
		service, legal considerations, obtaining
		approval prior to using external public
		services such as instant messaging or
		file sharing, stronger levels of
		authentication controlling access from
		publicly accessible networks.
Architecture	Cryptography		1. Inquire with control owner to	Inquiry,	1. Relevant agreements and
Layer		determine whether cryptographic	Inspection, and/or	guidance for applicable
		controls are used in compliance with	observation	legislation and regulations
		relevant agreements, legislation, and		2. Policies and procedures
		regulations.		related to encryption and
		2. Obtain and inspect the Encryption,		key management.
		and Cryptographic Controls. Encryption
		and Key Management security policies
		and procedures to determine that each
		type of cryptography is defined.
		Determine whether the policies outline
		the following:
		Tenant-specific encryption;
		Security requirements on
		cryptographic keys;
		Use of standardized cryptographic
		methods;
		Use of cryptographic keys.
Architecture	Scalability/Capacity	1. Inquire with the control owner and	Inquiry,	1. Provide Capacity
Layer	Management	determine if real time monitoring of	Inspection, and/or	Planning report
		system capacity is performed and the	observation	2. Provide screenshots of
		dashboard report is available for		monitoring dashboards
		management review.		3. ISMS Statement of
		2. Inspect the capacity monitoring tools		Applicability
		for a sample of production and sandbox
		instances and determine if they arc
		monitored in real time for. among
		others. CPU, API request time, web
		request time, transaction processing
		time, and report request times.
		3. Inspect if monitoring dashboards are
		available for management review, for
		individual instances and in aggregate, to
		enable real-time monitoring and future
		capacity planning
Architecture	Scalability/Capacity	1. Verify that there is a formally	Inquiry,	1. Audit and accountability
Layer	Management	documented capacity plan associated	Inspection, and/or	policies and procedures
		with critical systems and infrastructure.	observation	addressing audit storage
		2. Inquire with the control owner to		capacity
		determine whether business continuity		2. Evidence showing
		objectives are considered while		storage capacity.
		developing capacity plans.
		3. Review the capacity plan and validate
		that:
		Required capacity is provided, taking
		into account aspects such as normal
		workloads, contingencies, storage
		requirements and IT resource life
		cycles;
		Provisions such as prioritizing tasks,
		fault-tolerance mechanisms and
		resource allocation practices are in
		place:
		Business criticality of systems are
		taken into account while determining
		capacity:
		Projections of future capacity
		requirements take into account business
		strategy and plans.
Architecture	Scalability/Capacity	1. Examine security policies and	Inquiry,	1. Security policies and
Layer	Management	procedures to validate a process to	Inspection, and/or	procedures detailing
		follow up on availability, performance,	observation	process of remediating
		and capacity baselines exists		capacity deviations
		2. Examine sample of deviations from		2. Record of capacity
		availability, performance, and capacity		deviations and subsequent
		baselines and records which indicate		remediation actions taken
		appropriate actions were taken to		3. Executive/Board
		address outstanding issues.		reporting on handled
		3. Determine through inquiry and		capacity management
		inspection of reporting how follow up		incidents.
		activities to deviations are tracked,
		measured, and reported to executives or
		the Board of Directors.
Architecture	Availability	For in-scope Blockchain production	Inquiry,	1. System generated list of
Layer		systems:	Inspection, and/or	incident tickets for the
		1. Inquire with the control owner and	observation	period under review (to be
		determine whether production systems		specified) with screenshot
		are monitored for availability and		of parameters used to
		capacity, and any incidents arc		generate the listing.
		documented in a ticketing system.		2. Incident tickets for
		2. Obtain a population of incident		selected sample.
		tickets, select a sample, and inspect the		3. Incident dashboard for
		ticket details for the selected sample of		population of performance
		organization services incident tickets		incidents tickets for the
		from the workflow ticketing system and		period under review (to be
		determine whether the incident		specified).
		determine the incidents were assigned		4. Tickets for the samples
		an impacted environment, impacted		of high severity
		account, subject and description,		performance incidents
		incident type, severity rating, and
		customer impacted and were resolved or
		are being actively worked to resolution.
		3. Inspect the configurations within the
		monitoring tool for a sample of
		production servers, selected from the
		inventory management system, and
		determine whether the servers were
		configured to be monitored for
		availability and capacity and notify
		personnel in the event an issue was
		identified.
		4. Obtain a population of incident
		tickets, select a sample of high severity
		performance incident tickets, and
		inspect the sample of incident tickets to
		determine the incidents were assigned
		an impacted environment, impacted
		account, subject and description,
		incident type, severity rating, and
		customer impacted and were resolved or
		are being actively worked to resolution.

In some embodiments, blockchain architecture layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain architecture stack/layer supporting blockchain permissioned and/or permissioned networks operations and participant lifecycle management.
The sub-risk categories, control and testing objectives, test procedures and request lists for Operational Layer risk category are provided below in Tables 14-16.

TABLE 14

					Risk Level
Risk		Risk	Risk		(L, M, H)
Category	Domain	Classification	Number	Risk Description	(As applicable)

Operational Layer	Permissioned	Strategic,	OL-PN1	As the Blockchain is	L, M, H
	Network	Operational,		implemented, the nature of the
	Management	Financial,		instance (permissioned/non
		Compliance,		permissioned. use case etc.) is not
		Legal, or		aligned with and the governance
		Reputational		practices put in place.
Operational Layer	Participant	Strategic,	OL-PO1	User access controls are not	L, M, H
	Onboarding	Operational,		enforced, allowing unauthorized
	and Off-	Financial,		individuals to have access to
	boarding	Compliance,		systems and SOA services.
		Legal, or
		Reputational
Operational Layer	Application	Strategic,	OL-AL1	The Blockchain technology′s	L, M, H
	Layer	Operational,		impact on the controls attestations
		Financial,		(SOC 1/SOC 2 reports) or the
		Compliance,		Financial Statemcnt/SOX audit
		Legal, or		scope is not assessed and therefore
		Reputational		the potential impact is unknown
				and not managed.
Operational Layer	Application	Strategic,	OL-AL2	Risk and audit plans are not	L, M, H
	Layer	Operational,		updated and therefore do not
		Financial,		reflect and address the risks
		Compliance,		associated with the Blockchain
		Legal, or		technology.
		Reputational
Operational Layer	Blockchain	Strategic,	OL-BC1	Consensus mechanisms	L, M, H
	Concensus	Operational,		implemented do not provide
	Program	Financial,		comfort on the immutability of the
	Management	Compliance,		data stored on the Blockchain.
		Legal, or
		Reputational
Operational Layer	Blockchain	Strategic,	OL-BC2	Consensus mechanisms	L, M, H
	Concensus	Operational,		implemented do not provide
	Program	Financial,		comfort on the immutability of the
	Management	Compliance,		data stored on the Blockchain.
		Legal, or
		Reputational
Operational Layer	Integration	Strategic,	OL-IW1	The setup of the Blockchain	L, M, H
	with off-	Operational,		software lacks consideration of
	Blockchain	Financial,		new security requirements to
	Systems and	Compliance,		maintain confidentiality, integrity,
	Processes	Legal, or		and availability.
		Reputational
Operational Layer	Integration	Strategic,	OL-IW2	Hardware (including	L, M, H
	with off-	Operational,		configurations, locations,
	Blockchain	Financial,		capacity/capacity utilization, and
	Systems and	Compliance,		age and data requirements)
	Processes	Legal, or		impacted by the Blockchain
		Reputational		integration have not been
				collected and evaluated,
				potentially causing an unknown
				impact.
Operational Layer	Integration	Strategic,	OL-IW3	Applications, software and	L, M, H
	with off-	Operational,		software components impacted by
	Blockchain	Financial,		the Blockchain software
	Systems and	Compliance,		integration have not been
	Processes	Legal, or		identified and evaluated.
		Reputational
Operational Layer	Integration	Strategic,	OL-IW4	User access and segregation of	L, M, H
	with off-	Operational,		duties controls are not enforced,
	Blockchain	Financial,		allowing unauthorized users to
	Systems and	Compliance,		migrate Blockchain process
	Processes	Legal, or		configurations into production.
		Reputational
Operational Layer	Integration	Strategic,	OL-IW5	System development or	L, M, H
	with off-	Operational,		maintenance on a system with
	Blockchain	Financial,		Blockchain dependencies are not
	Systems and	Compliance,		identified and evaluated,
	Processes	Legal, or		potentially causing an unknown
		Reputational		impact.
Operational Layer	Integration	Strategic,	OL-IW6	The legacy system Software	L, M, H
	with off-	Operational,		Development Lifecycle
	Blockchain	Financial,		methodology for change
	Systems and	Compliance,		management processes docs not
	Processes	Legal, or		reflect the integration with the
		Reputational		Blockchain program management.
Operational Layer	Integration	Strategic,	OL-IW7	Business process changes with	L, M, H
	with off-	Operational,		Blockchain dependencies are not
	Blockchain	Financial,		identified and evaluated,
	Systems and	Compliance,		potentially causing an unknown
	Processes	Legal, or		impact.
		Reputational
Operational Layer	Smart	Strategic,	OL-SC2	Blockchain data is stored on off-	L, M, H
	Contracts	Operational,		chain databases that are unsecure
		Financial,
		Compliance,
		Legal, or
		Reputational
Operational Layer	Smart	Strategic,	OL-SC3	The organization lacks a complete	L, M, H
	Contracts	Operational,		governance structure to provide
		Financial,		oversight and security for hard
		Compliance,		forks in the blockchain
		Legal, or		architecture
		Reputational

TABLE 15

				In-scope/Out-of-
				scope (TBD-As
Risk Category	Domain	Control/Test Objective	Control Description	per engagement)

Operational	Permissioned	As the Blockchain is implemented,	A Blockchain steering	In-scope
Layer	Network	there is alignment with the nature of	committee, which includes
	Management	the instance (permissioned/non	executive leadership and senior
		permissioned. use case etc.) and the	members of the business, risk,
		governance practices put in place.	compliance and the Blockchain
		An appropriate governance regime is	program management, meets on
		designed and agreed, if required	a quarterly basis to conduct
		across all participants in the network.	business performance reviews of
			how the Blockchain aligns with
			IT Governance.
Operational	Participant	All access is logged and monitored	All access is logged and	In-scope
Layer	Onboarding	and SOA services maintain the	monitored.
	and Off-	appropriate restricted access.	SOA services are restricted from
	boarding		being accessed by anyone other
			than whitelisted
			processes/clients.
Operational	Application	Management has engaged appropriate	The Blockchain Program	In-scope
Layer	Layer	members of internal and external audit	management meets with external
		to assess if the Blockchain technology	SOC	1/Financial Statement audit
		will have an impact on the controls	teams to review the status of the
		attestations (SOC 1/SOC 2 reports) or	project plan and future the
		the Financial Statement/SOX audit	Blockchain process
		scope.	considerations and
			management′s assessment on
			impact of the Blockchain
			technology to the audit scope.
Operational	Application	Internal audit has been properly	The Blockchain management	In-scope
Layer	Layer	engaged and the Blockchain program	team meets regularly with
		is being considered in the internal	members of risk and internal
		audit scoping exercises.	audit in each business unit
			leveraging the Blockchain
			technology to ensure the risk and
			audit plans are evolving to
			address the Blockchain risks.
Operational	Blockchain	As Blockchain programs are designed	Blockchain consensus	In-scope
Layer	Consensus	and implemented, appropriate	mechanisms that assure
	Program	consensus mechanisms are agreed	immutability are designed
	Management	upon, implemented and controlled to	implemented and the associated
		provide comfort on the immutability	controls are documented and
		of the data stored on the Blockchain.	approved by the business and the
		Appropriate controls are designed and	Blockchain program
		implemented to safeguard the	management. Blocks are created
		immutability of data captured on the	for transactions validated
		blockchain.	through blockchain consensus
			mechanism and cannot be
			modified once written.
Operational	Blockchain	Conesus mechanism automatically	Economic trade terms arc	In-scope
Layer	Consensus	determines whether the trade details	validated through blockchain
	Program	match between counterparties or not.	consensus mechanism and
	Management	Automatic validation will not take	automatically recorded on the
		place if consensus is not reached.	blockchain network in a timely
			manner.
Operational	Integration	The Blockchain software is aligned	The Blockchain software for
Layer	with off-	with new security requirements to	initial integration into the firm′s
	Blockchain	maintain confidentiality, integrity, and	environment follows a well-
	Systems and	availability.	defined integration plan and is
	Processes		monitored by the Blockchain
			program management.
Operational	Integration	Hardware impacted by the Blockchain	Impact of software integration	In-scope
Layer	with off-	integration is documented and	on the firm′s existing hardware
	Blockchain	evaluated, and results are escalated to	configurations, software and
	Systems and	the Blockchain steering committee.	applications is documented and
	Processes		evaluated. The results of this
			evaluation are reported to the
			Blockchain steering committee.
Operational	Integration	Applications and software impacted	Impact of software integration	In-scope
Layer	with off-	by the Blockchain integration is	on the firm′s existing hardware
	Blockchain	documented and evaluated, and results	configurations, software and
	Systems and	are escalated to the Blockchain	applications is documented and
	Processes	steering committee.	evaluated. The results of this
			evaluation are reported to the
			Blockchain steering committee.
Operational	Integration	Operations policies and procedures	Access to migrate the	In-scope
Layer	with off-	have been updated to include	Blockchain process
	Blockchain	integration with the Blockchain prior	configurations into production is
	Systems and	to the Blockchain change being placed	restricted to personnel who are
	Processes	into production.	independent of the configuration
			team. Access to migrate the
			Blockchain process
			configurations into production is
			periodically reviewed to ensure
			access is restricted to personnel.
Operational	Integration	Impact of legacy system development	Business Unit IT management	In-scope
Layer	with off-	and maintenance on the Blockchain	notifies the Blockchain program
	Blockchain	configuration is considered during	management if system
	Systems and	legacy System Development Lifecycle	development or maintenance on
	Processes	for legacy systems.	a system has been identified as
		Impacts to interfaces between legacy	having the Blockchain
		systems have been identified., e.g.	dependencies. The Blockchain
		data flow architecture	program management evaluates
			the impact the legacy system
			change will have on the
			Blockchain. Details of the
			evaluation are documented. If
			the Blockchain process is
			impacted, the Blockchain is
			removed from production and a
			back out plan is enabled while a
			configuration change order is
			processed.
Operational	Integration	An inventory, including functional	The legacy system Software	In-scope
Layer	with off-	use. of all key interfaces and legacy	Development Lifecycle
	Blockchain	systems utilized by the Blockchain is	methodology for change
	Systems and	maintained.	management processes has been
	Processes	Impacts to interfaces between legacy	updated to include integration
		systems have been identified., e.g.	with the Blockchain program
		data flow architecture	management prior to making
			changes to the Blockchain
			impacted systems or interfaces.
Operational	Integration	The Blockchain is reconfigured when	Business Unit Operations	In-scope
Layer	with off-	changes in business processes affect	management notifies the
	Blockchain	the Blockchain. Management	Blockchain program
	Systems and	considers both the downstream and	management if a business
	Processes	upstream impact of changes to	process change has been
		business processes and the use of the	identified as having the
		Blockchain technology.	Blockchain dependencies. The
			Blockchain program
			management evaluates the
			impact the business process
			change will have on the
			Blockchain configuration.
			Details of the evaluation are
			documented. If a Blockchain
			process is impacted, the
			Blockchain is removed from
			production and back out plan is
			enabled while a configuration
			change order is processed.

TABLE 16

			Test Type
			(TBD—
Risk			As per
Category	Domain	Test Procedure (#)	engagement)	Request List (#)

Operational	Permissioned		1. Inquire with management about the process of	Inquiry,	1. Listing of the
Layer	Network	ensuring alignment with the nature of the instance	Inspection,	individuals on the
	Management	and the government practices put in place.	and/or	Blockchain steering
		2. Obtain relevant documentation evidencing the	observation	committee
		consideration of the alignment.		2. Evidence for the
		3. Obtain a listing of the individuals on the		most recent quarterly
		Blockchain steering committee.		meeting (meeting
		4. Obtain evidence for the most recent quarterly		minutes/meeting
		meeting (meeting minutes/meeting invites) to		invites/emails)
		verify that meeting took place and included		showing the meeting
		members of the Blockchain steering committee.		took place
		5. Through inspection of the results of business		3. Documentation/
		performance review, verify an appropriate review		results of the
		was performed of how the Blockchain aligns with		quarterly business
		IT Governance.		performance review
				of how the Block-
				chain aligns with
				IT Governance
				4. Documentation
				leveraged when
				considering the
				alignment
Operational	Participant		1. Inquire with management about the process	Inquiry,	1. Listing of users with
Layer	Onboarding	and frequency in which access is logged and	Inspection,	access to the SOA
	and Off-	monitored.	and/or	services
	boarding	2. Obtain a listing of users with access to the	observation	2. Documentation
		SOA services.		showing all access is
		3. Obtain documentation showing that all access		logged and monitored
		is logged and monitored and through inspection,		3. Screenshot showing
		verify that only users with permissioned access		how access is logged
		appear on the listing.		and monitored
Operational	Application		1. Obtain evidence for the most recent meeting	Inquiry,	1. Evidence for the
Layer	Layer	(meeting minutes/meeting invites) to verify the	Inspection,	most recent meeting
		meeting took place and included members of the	and/or	(meeting
		Blockchain Program management team.	observation	minutes/meeting
		2. Through inspection of the documentation of the		invites/emails)
		assessment, verify the assessment was performed		showing the meeting
		and the results were documented.		took place
				2. Documentation of
				management's
				assessment on the
				impact of the
				Blockchain technology
				to the audit scope
Operational	Application		1. Obtain evidence for the most recent meeting	Inquiry,	1. Evidence for the
Layer	Layer	(meeting minutes/meeting invites) to verify the	Inspection,	most recent meeting
		meeting took place and included members of the	and/or	(meeting
		Blockchain management team.	observation	minutes/meeting
		2. Through inspection of an updated risk and audit		invites/emails)
		plan, verify changes and updates have been made		showing the meeting
		to reflect the Blockchain program.		took place
				2. Risk and audit plan
				updated to address
				Blockchain risks
Operational	Blockchain		1. Inquire with management about the process in	Inquiry,	1. Documentation of
Layer	Consensus	which appropriate consensus mechanisms are	Inspection,	the associated controls
	Program	agreed upon, implemented and controlled,	and/or	for a new Blockchain
	Management
	2. Obtain documentation of the associated	observation	consensus mechanism
		controls.		2. Evidence of the
		3. Through inspection of documentation		review and approval
		evidencing associated controls have been		by the business and the
		documented, verify these controls were reviewed		Blockchain program
		and approved by the business and the Blockchain		management
		program management.
Operational	Blockchain		1. Inquire with management about the process in	Inquiry,
Layer	Consensus	which appropriate consensus mechanisms are	Inspection,
	Program	agreed upon, implemented and controlled.	and/or
	Management	2. Obtain documentation of the associated	observation
		controls.
		3. Through inspection of documentation
		evidencing associated controls have been
		documented, verify these controls were reviewed
		and approved by the business and the Blockchain
		program management.
Operational	Integration		1. Inquire with management about the process of	Inquiry,	1. Integration plan used
Layer	with off-	ensuring alignment with new security	Inspection,	for initial integration
	Blockchain	requirements.	and/or	2. Evidence showing
	Systems and	2. Obtain the integration plan used for initial	observation	the integration plan is
	Processes	integration.		monitored
		3. Through inspection of the integration plan,
		verify that there is evidence that the integration
		plan is monitored by the Blockchain program
		management.
Operational	Integration		1. Obtain the documentation of the impact of	Inquiry,	1. Documentation
Layer	with off-	software integration	Inspection,	showing the evaluation
	Blockchain
	2. Through inspection of the documentation,	and/or	performed of the
	Systems and	verify any impacts identified were appropriately	observation	impact of software
	Processes	evaluated.		integration on the
		3. Obtain evidence of the communicated results		firm's existing
		and through inspection, verify the results of the		hardware
		evaluation were reported to the Blockchain		configurations
		steering committee.		2. Evidence of
				communication to the
				Blockchain steering
				committee
Operational	Integration		1. Obtain the documentation of the impact of	Inquiry,	1. Documentation
Layer	with off-	software integration.	Inspection,	showing the evaluation
	Blockchain
	2. Through inspection of the documentation,	and/or	performed of the
	Systems and	verify any impacts identified were appropriately	observation	impact of software
	Processes	evaluated.		integration on the
		3. Obtain evidence of the communicated results,		firm's existing
		and through inspection, verify the results of the		hardware
		evaluation were reported to the Blockchain		configurations
		steering committee.		2. Evidence of
				communication to the
				Blockchain steering
				committee
Operational	Integration		1. Obtain a listing of users with access to migrate	Inquiry,	1. Listing of users with
Layer	with off-	the Blockchain process configurations.	Inspection,	access to migrate the
	Blockchain	2. Obtain evidence for the most recent periodic	and/or	Blockchain process
	Systems and	review performed of access, and through	observation	configurations
	Processes	inspection verify access was restricted to		2. Evidence that a
		personnel.		periodic review was
		3. Obtain the Operations policies and procedures		performed of restricted
		Blockchain evidencing the updates made to		access and including
		include integration with the Blockchain with		evidence of the review
		a date in which these updates were made.		3. Operations policies
		4. Obtain evidence of the Blockchain change		and procedures updated
		being placed into production and the date in		with the integration
		which this occurred.		with Blockchain with
		5. Through inspection, verify the updates were		the date in which the
		made to the policies and procedures prior to the		updates were made
		change being placed into production.		4. Evidence of the
				change being placed
				into production
				(change order ticket
				including the date in
				which the request was
				processed and
				completed)
Operational	Integration		1. Obtain evidence of communication between	Inquiry,	1. Evidence of
Layer	with off-	Business Unit IT management and the Blockchain	Inspection,	communication
	Blockchain	program management of a system identified as	and/or	between Business Unit
	Systems and	having Blockchain dependencies.	observation	IT management and the
	Processes	2. Verify the Blockchain program management		Blockchain program
		performed an evaluation of the impact the legacy		management for a
		system change has on the Blockchain.		system identified as
		3. Obtain documentation verifying the details of		having Blockchain
		the evaluation were documented.		dependencies
		4. Obtain evidence of a processed change order		2. Evaluation
		request to remove the Blockchain from production		performed by the
		and through inspection, verify the request was		Blockchain program
		completed.		management
		5. Obtain documentation of the back out plan and		3. Evidence that the
		through inspection, verify that the back out plan		Blockchain was
		was enabled while a configuration change order		removed from
		was processed.		production
				4. Change order ticket
				showing this request
				was processed and
				completed
				5. Back out plan that
				was enabled
Operational	Integration		1. Inquire with management about the process of	Inquiry,	1. The legacy system
Layer	with off-	updating the methodology to include integration	Inspection,	Software Development
	Blockchain	with Blockchain program management.	and/or	Lifecycle methodology
	Systems and	2. Obtain documentation verifying change	observation	for change
	Processes	management processes have been updated with		management processes
		the date in which these updates were made.		updated with
		3. Obtain evidence of the changes made to the		Blockchain with the
		Blockchain and the date in which these changes		date in which the
		were made.		updates were made
		4. Through inspection, verify that the updates		2. Evidence of the
		were made to the methodology prior to the		changes made to the
		changes being made.		Blockchain impacted
		5. Obtain the inventory listing and through		system (change order
		inspection, verify the listing includes functional		ticket including the
		use of all key interfaces and legacy systems		date in which the
		utilized by the Blockchain and that the listing is		request was processed
		properly maintained.		and completed)
				3. Inventory listing
				with evidence of how
				the listing is
				maintained
Operational	Integration		1. Obtain evidence of communication between	Inquiry,	1. Evidence of
Layer	with off-	Business Unit Operations and the Blockchain	Inspection,	communication
	Blockchain	program management of a business process	and/or	between Business Unit
	Systems and	identified as having Blockchain dependencies.	observation	IT management and the
	Processes	2. Verify the Blockchain program management		Blockchain program
		performed an evaluation of the impact the legacy		management
		system change has on the Blockchain.		2. Evaluation
		3. Obtain evidence verifying the details of the		performed by the
		evaluation were documented.		Blockchain program
		4. Obtain evidence of a processed change order		management
		request to remove the Blockchain from production		3. Evidence that the
		and through inspection, verify the request was		Blockchain was
		completed.		removed from
		5. Obtain documentation of the back out plan and		production
		through inspection, verify that the back out plan		4. Change order ticket
		was enabled while a configuration change order		showing this request
		was processed.		was processed
				5. Back out plan that
				was enabled

4.6 Transactional Layer Assessment Work Program

In some embodiments, transaction layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain application stack/layer supporting business and transaction level processing.
The sub-risk categories, control and testing objectives, test procedures and request lists for Transactional Layer risk category are provided below in Tables 17-19.

TABLE 17

					Risk Level
					(L, M, H)
Risk		Risk	Risk		(As
Category	Domain	Classification	Number	Risk Description	applicable)

Transactional	Smart	Strategic,	TL-SC1	Incorrect SC terms are not	L, M, H
(Business)	Contracts	Operational,		selected for execution.
	(SC)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC2	SC terms and conditions are	L, M, H
(Business)	Contracts	Operational,		not inclusive of required
	(SC)	Financial,		information or standard
		Compliance/		terms and conditions.
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC3	SC is executed with wrong/	L, M, H
(Business)	Contracts	Operational,		incorrect participants or SC
	(SC)	Financial,		does not include right/correct
		Compliance/		participants.
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC4	SC is not reviewed, appraised,	L, M, H
(Business)	Contracts	Operational,		and approved by appropriate
	(SC)	Financial,		participants during or before
		Compliance/		execution.
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC5	SC is completed without	L, M, H
(Business)	Contracts	Operational,		execution of required terms
	(SC)	Financial,		and conditions by all
		Compliance/		participants.
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC6	Required events (e.g.	L, M, H
(Business)	Contracts	Operational,		invoicing, payments, change
	(SC)	Financial,		or ownership) are not initiated
		Compliance/		and completed successfully
		Legal,		during or after SC execution.
		Reputational
Transactional	Smart	Strategic,	TL-SC7	Privileged access is not	L, M, H
(Business)	Contracts	Operational,		appropriately restricted, logged,
	(SC)	Financial,		and monitored for Smart
		Compliance/		Contracts, which can create a
		Legal,		risk of unauthorized access to
		Reputational		Smart Contracts by developers/
				admins/database admins
Transactional	Smart	Strategic,	TL-SC8	End-user access is not	L, M, H
(Business)	Contracts	Operational,		appropriately restricted, creating
	(SC)	Financial,		the risk of unauthorized changes/
		Compliance/		deployments/executions/updates/
		Legal,		modifications performed for the
		Reputational		Smart Contract and workflow
Transactional	Smart	Strategic,	TL-SC9	Smart Contract development and	L, M, H
(Business)	Contracts	Operational,		change management process is
	(SC)	Financial,		not in place and followed, which
		Compliance/		may lead to unauthorized
		Legal,		unilateral actions by developers
		Reputational		to modify or remove Smart
				Contract functions or introduce
				unnecessary or insecure functions
Transactional	Smart	Strategic,	TL-SC10	Smart Contract development and	L, M, H
(Business)	Contracts	Operational,		change management process is
	(SC)	Financial,		not in place and followed, which
		Compliance/		may lead to inappropriate and
		Legal,		incorrect terms and conditions
		Reputational		[e.g. timeline, pricing, resources,
				invoicing, settlement, etc.]
				defined for the Smart Contract
Transactional	Smart	Strategic,	TL-SC11	Smart Contract development and	L, M, H
(Business)	Contracts	Operational,		change management process is
	(SC)	Financial,		not in place and followed, which
		Compliance/		may lead to inappropriate and
		Legal,		incorrect assets and services
		Reputational		defined for the Smart Contract
Transactional	Smart	Strategic,	TL-SC12	Smart Contract development and	L, M, H
(Business)	Contracts	Operational,		change management process is
	(SC)	Financial,		not in place and followed, which
		Compliance/		may lead to inappropriate and
		Legal,		incorrect participants defined for
		Reputational		the Smart Contract
Transactional	Smart	Strategic,	TL-SC13	Smart Contract development and	L, M, H
(Business)	Contracts	Operational,		change management process is
	(SC)	Financial,		not in place and followed, which
		Compliance/		may lead to unauthorized or
		Legal,		incorrect Smart Contracts being
		Reputational		introduced into the production
				environment
Transactional	Smart	Strategic,	TL-SC14	Unauthorized access to Blockchain	L, M, H
(Business)	Contracts	Operational,		metadata or PII by unauthorized
	(SC)	Financial,		parties for development or testing
		Compliance/		purposes
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC15	Data is not retained for DLT inputs.	L, M, H
(Business)	Contracts	Operational,		PKIs. or other critical systems; lack
	(SC)	Financial,		of availability limits backup and
		Compliance/		recovery capability
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC16	Input validation mechanisms for	L, M, H
(Business)	Contracts	Operational,		fields and records are not in place,
	(SC)	Financial,		which may compromise the Smart
		Compliance/		Contract execution
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC17	Security mechanisms are not in	L, M, H
(Business)	Contracts	Operational,		place or effective in protecting
	(SC)	Financial,		output (data), creating the risk
		Compliance/		of unauthorized access or changes
		Legal,		made to output
		Reputational
Transactional	Smart	Strategic,	TL-SC18	Security mechanisms are not in	L, M, H
(Business)	Contracts	Operational,		place or effective in protecting
	(SC)	Financial,		Smart Contracts mid their
		Compliance/		exposure to unauthorized parties
		Legal,		via export and sharing
		Reputational		functionalities
Transactional	Smart	Strategic,	TL-SC19	Mechanisms are not in place or	L, M, H
(Business)	Contracts	Operational,		effective in ensuring subsequent
	(SC)	Financial,		Smart Contracts are only triggered
		Compliance/		when appropriate and when needed
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC20	Mechanisms are not in place or	L, M, H
(Business)	Contracts	Operational,		effective in ensuring subsequent
	(SC)	Financial,		smart contracts, invoicing, billing
		Compliance/		is triggered and processed
		Legal,		appropriately as and if needed
		Reputational
Transactional	Smart	Strategic,	TL-SC21	Mechanisms are not in place or	L, M, H
(Business)	Contracts	Operational,		effective in ensuring subsequent
	(SC)	Financial,		movement of digital assets is
		Compliance/		triggered and processed
		Legal,		appropriately as and if needed
		Reputational
Transactional	Smart	Strategic,	TL-SC22	Mechanisms are not in place or	L, M, H
(Business)	Contracts	Operational,		effective in ensuring subsequent
	(SC)	Financial,		digital tokens are triggered and
		Compliance/		processed appropriately as and
		Legal,		if needed
		Reputational
Transactional	Smart	Strategic,	TL-SC23	Monitoring mechanisms are not	L, M, H
(Business)	Contracts	Operational,		in place for Smart Contracts,
	(SC)	Financial,		which can lead to non-detection
		Compliance/		of Smart Contracts not performing
		Legal,		as intended in the production
		Reputational		environment
Transactional	Smart	Strategic,	TL-SC24	Monitoring mechanisms are not in	L, M, H
(Business)	Contracts	Operational,		place for Smart Contracts, which
	(SC)	Financial,		can create a risk of impaired
		Compliance/		network performance or latency
		Legal,
		Reputational
Transactional	Smart	Strategic,	TL-SC25	Monitoring mechanisms are not	L, M, H
(Business)	Contracts	Operational,		in place for Smart Contracts,
	(SC)	Financial,		which can create a risk of the
		Compliance/		Smart Contract not being
		Legal,		executed and completed as
		Reputational		per defined terms
Transactional	Smart	Strategic,	TL-SC26	Monitoring mechanisms are not	L, M, H
(Business)	Contracts	Operational,		in place for Smart Contracts,
	(SC)	Financial,		which can create a risk of the
		Compliance/		Smart Contract not being retired
		Legal,		appropriately if necessary
		Reputational
Transactional	Smart	Strategic,	TL-SC27	Monitoring mcclianisms are not	L, M, H
(Business)	Contracts	Operational,		in place for Smart Contracts,
	(SC)	Financial,		which can create a risk of the
		Compliance/		Smart Contract being deployed,
		Legal,		modified, or changed by
		Reputational		unauthorized participants
Transactional	Smart	Strategic,	TL-SC28	Smart Contract privacy is not	L, M, H
(Business)	Contracts	Operational,		maintained throughout the
	(SC)	Financial,		Smart Contract lifecycle,
		Compliance/		creating tire risk of private
		Legal,		information being divulged,
		Reputational		shared, or disseminated
Transactional	Smart	Strategic,	TL-SC29	Interfaces are not configured	L, M, H
(Business)	Contracts	Operational,		to ensure all process data
	(SC)	Financial,		transmissions within the
		Compliance/		blockchain are complete,
		Legal,		accurate, and secure
		Reputational
Transactional	Smart	Strategic,	TL-SC30	Interfaces are not configured	L, M, H
(Business)	Contracts	Operational,		to ensure all process data
	(SC)	Financial,		transmissions to off-chain
		Compliance/		platforms or systems are
		Legal,		complete, accurate, and secure
		Reputational
Transactional	Smart	Strategic,	TL-SC31	Smart Contract arehitecture is	L, M, H
(Business)	Contracts	Operational,		unable to be updated/modified
	(SC)	Financial,		and therefore docs not comply
		Compliance/		with new requirements or
		Legal,		regulations or is vulnerable to
		Reputational		newly-discovered security issues
Transactional	Smart	Strategic,	TL-SC32	Insufficient side chain safeguards	L, M, H
(Business)	Contracts	Operational,		increase risk of incidents leading
	(SC)	Financial,		to loss or invalidation of assets or
		Compliance/		transactions related to Smart
		Legal,		Contracts
		Reputational
Transactional	Digital	Strategic,	TL-DA1	Incorrectly DA onboarding may	L, M, H
(Business)	Assets	Operational,		cause delay or compromise
	(DA)	Financial,		transactional level processing.
		Compliance/
		Legal,
		Reputational
	Digital	Strategic,	TL-DA2	DA ownership is transferred	L, M, H
	Assets	Operational,		incorrectly which may compromise
	(DA)	Financial,		transactional level processing.
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DA3	DA is not managed and maintained	L, M, H
(Business)	Assets	Operational,		appropriately during its lifecycle.
	(DA)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DA4	DA is not retired appropriately at	L, M, H
(Business)	Assets	Operational,		the end of the lifecycle.
	(DA)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DA5	Privileged access is not	L, M, H
(Business)	Assets	Operational,		appropriately restricted, logged,
	(DA)	Financial,		and monitored for Digital Assets,
		Compliance/		which can lead to unauthorized
		Legal,		access
		Reputational
Transactional	Digital	Strategic,	TL-DA6	End-user access is not appropriately	L, M, H
(Business)	Assets	Operational,		restricted, creating the risk of
	(DA)	Financial,		unauthorized changes/deployments/
		Compliance/		executions/updates/modifications
		Legal,		performed for the Digital Assets
		Reputational		and workflow
Transactional	Digital	Strategic,	TL-DA7	Digital Assets are not configured	L, M, H
(Business)	Assets	Operational,		with strong login credentials and
	(DA)	Financial,		account security protocols to
		Compliance/		restrict unauthorized access
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DA8	Digital Assets are stored in an	L, M, H
(Business)	Assets	Operational,		unsecure environment, and hot/
	(DA)	Financial,		warm/cold risk factors systemic
		Compliance/		to each Digital Asset platform
		Legal,		are not taken into account,
		Reputational		creating greater risks to Digital
				Asset operations and security
				of transaction data
Transactional	Digital	Strategic,	TL-DA9	Participants are not	L, M, H
(Business)	Assets	Operational,		appropriately and correctly
	(DA)	Financial,		defined which can lead to
		Compliance/		unauthorized access or
		Legal,		operation of the Digital Asset
		Reputational
Transactional	Digital	Strategic,	TL-DA10	Digital Assets are not	L, M, H
(Business)	Assets	Operational,		appropriately or correctly
	(DA)	Financial,		protected, managed, and
		Compliance/		monitored throughout
		Legal,		their life cycle
		Reputational
Transactional	Digital	Strategic,	TL-DA11	Unauthorized or incorrect	L, M, H
(Business)	Assets	Operational,		Digital Asset platforms tire
	(DA)	Financial,		introduced, compromising the
		Compliance/		security of the organization's
		Legal,		Digital Asset environment
		Reputational
Transactional	Digital	Strategic,	TL-DA12	Digital Asset software is not	L, M, H
(Business)	Assets	Operational,		updated in accordance with
	(DA)	Financial,		required updates, leading to
		Compliance/		version mismatching and
		Legal,		potential compromises to
		Reputational		security or operational limitations
Transactional	Digital	Strategic,	TL-DA13	Digital Asset management	L, M, H
(Business)	Assets	Operational,		platforms are not configured
	(DA)	Financial,		with recover) procedures to
		Compliance/		recover loss of data and
		Legal,		information
		Reputational
Transactional	Digital	Strategic,	TL-DA14	Mechanisms are not in place	L, M, H
(Business)	Assets	Operational,		or effective in ensuring Digital
	(DA)	Financial,		Asset transactions are triggered
		Compliance/		as and if needed
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DA15	Monitoring mechanisms are not	L, M, H
(Business)	Assets	Operational,		in place for Digital Assets, which
	(DA)	Financial,		can lead to non-detection of
		Compliance/		Digital Assets not performing as
		Legal,		intended in the production
		Reputational		environment
Transactional	Digital	Strategic,	TL-DA16	Monitoring mechanisms are not	L, M, H
(Business)	Assets	Operational,		in place for Digital Assets,
	(DA)	Financial,		which can create a risk of
		Compliance/		impaired network performance
		Legal,		or latency
		Reputational
Transactional	Digital	Strategic,	TL-DA17	Monitoring mechanisms tire	L, M, H
(Business)	Assets	Operational,		not in place for Digital Assets,
	(DA)	Financial,		which can create a risk of a
		Compliance/		Digital Asset not being utilized
		Legal,		per defined terms
		Reputational
Transactional	Digital	Strategic,	TL-DA18	Monitoring mechanisms are	L, M, H
(Business)	Assets	Operational,		not in place for Digital Assets,
	(DA)	Financial,		which can create a risk of the
		Compliance/		Digital Asset not being retired
		Legal,		appropriately if neccssary
		Reputational
Transactional	Digital	Strategic,	TL-DA19	Monitoring mechanisms are	L, M, H
(Business)	Assets	Operational,		not in place for Digital Assets,
	(DA)	Financial,		which can create a risk of the
		Compliance/		Digital Asset being utilized,
		Legal,		modified, or changed by
		Reputational		unauthorized participants
Transactional	Digital	Strategic,	TL-DA20	Digital Asset privacy is not	L, M, H
(Business)	Assets	Operational,		maintained throughout the
	(DA)	Financial,		Digital Asset lifecycle, creating
		Compliance/		the risk of private information
		Legal,		being divulged, shared, or
		Reputational		disseminated
Transactional	Digital	Strategic,	TL-DA21	Interfaces are not configured to	L, M, H
(Business)	Assets	Operational,		ensure all process data
	(DA)	Financial,		transmissions within the
		Compliance/		blockchain are complete,
		Legal,		accurate, and secure
		Reputational
Transactional	Digital	Strategic,	TL-DA22	Interfaces are not configured to	L, M, H
(Business)	Assets	Operational,		ensure all process data
	(DA)	Financial,		transmissions to off-chain
		Compliance/		platforms or systems are
		Legal,		complete, accurate, and secure
		Reputational
Transactional	Digital	Strategic,	TL-DA23	Without price fluctuation	L, M, H
(Business)	Assets	Operational,		monitoring and defined
	(DA)	Financial,		response/action plan, assets,
		Compliance/		contracts, tokens can be
		Legal,		processed with incorrect
		Reputational		value at a given point in time
Transactional	Digital	Strategic,	TL-DA24	Fluctuations in prices for	L, M, H
(Business)	Assets	Operational,		commodity items like Digital
	(DA)	Financial,		Asset storage create
		Compliance/		opportunities for sunk costs
		Legal,		or deadweight loss
		Reputational		expenditures
Transactional	Digital	Strategic,	TL-DA25	Digital Assets within the	L, M, H
(Business)	Assets	Operational,		organization are not linked
	(DA)	Financial,		with soft or intangible assets
		Compliance/		(i.e. human resources)
		Legal,		causing lack of operational
		Reputational		alignment across the
				organization
Transactional	Digital	Strategic,	TL-DA26	Digital Assets within the	L, M, H
(Business)	Assets	Operational,		organization are not linked
	(DA)	Financial,		with other real world assets
		Compliance/		(i.e. real estate, property,
		Legal,		etc.) causing lack of
		Reputational		operational alignment across
				the organization
Transactional	Digital	Strategic,	TL-DA27	The existence of physical/	L, M, H
(Business)	Assets	Operational,		logical assets is not tracked
	(DA)	Financial,		or managed on a regular
		Compliance/		basis, causing inaccurate
		Legal,		and incomplete
		Reputational		representation of physical
				assets in a digital form
Transactional	Digital	Strategic,	TL-DA28	The organization's legacy	L, M, H
(Business)	Assets	Operational,		system accounts are not
	(DA)	Financial,		linked with DLT associated
		Compliance/		Digital Assets, causing lack
		Legal,		of operational alignment
		Reputational		across the organization
Transactional	Digital	Strategic,	TL-DT1	Participants are not on-	L, M, H
(Business)	Tokens	Operational,		boarded for DC transactions.
	(DT)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT2	Account balance cannot	L, M, H
(Business)	Tokens	Operational,		support DC transaction
	(DT)	Financial,		request for processing.
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT3	DC-in requests are not	L, M, H
(Business)	Tokens	Operational,		processed correctly.
	(DT)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT4	DC-out requests are not	L, M, H
(Business)	Tokens	Operational,		processed correctly.
	(DT)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT5	DC duplicate transactions	L, M, H
(Business)	Tokens	Operational,		are processed.
	(DT)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT6	DC transactions are	L, M, H
(Business)	Tokens	Operational,		approved.
	(DT)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT7	DC transaction information	L, M, H
(Business)	Tokens	Operational,		is missing which may
	(DT)	Financial,		compromise transaction
		Compliance/		processing.
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT8	Address is not generated or	L, M, H
(Business)	Tokens	Operational,		shared with participants for
	(DT)	Financial,		DC transactions.
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT9	Cancelled or failed	L, M, H
(Business)	Tokens	Operational,		transactions are not tracked
	(DT)	Financial,		or processed correctly.
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT10	DC is not moved from one	L, M, H
(Business)	Tokens	Operational,		participant to the other (e.g.
	(DT)	Financial,		payor and payee) correctly
		Compliance/		and in a timely manner.
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT11	DC is not evaluated correctly	L, M, H
(Business)	Tokens	Operational,		relative to underlying asset or
	(DT)	Financial,		currency.
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT12	Privileged access is not	L, M, H
(Business)	Tokens	Operational,		appropriately restricted,
	(DT)	Financial,		logged, and monitored for
		Compliance/		Digital Tokens, which can
		Legal,		lead to unauthorized access
		Reputational
Transactional	Digital	Strategic,	TL-DT13	End-user access is not	L, M, H
(Business)	Tokens	Operational,		appropriately restricted,
	(DT)	Financial,		which can lead to
		Compliance/		unauthorized changes/
		Legal,		updates/modifications
		Reputational		performed for the Digital
				Tokens and workflow
Transactional	Digital	Strategic,	TL-DT14	Digital Tokens are not	L, M, H
(Business)	Tokens	Operational,		configured with strong
	(DT)	Financial,		login credentials and
		Compliance/		account security protocols
		Legal,		to restrict unauthorized
		Reputational		access
Transactional	Digital	Strategic,	TL-DT15	Digital Token development	L, M, H
(Business)	Tokens	Operational,		and change management
	(DT)	Financial,		process is not in place and
		Compliance/		followed, which may lead to
		Legal,		inappropriate and incorrect
		Reputational		participants defined for
				authorized use of Digital Tokens
Transactional	Digital	Strategic,	TL-DT16	Digital Tokens are not	L, M, H
(Business)	Tokens	Operational,		appropriately or correctly
	(DT)	Financial,		protected, managed, and
		Compliance/		monitored throughout their
		Legal,		life
		Reputational
Transactional	Digital	Strategic,	TL-DT17	Digital Tokens are not	L, M, H
(Business)	Tokens	Operational,		monitored appropriately
	(DT)	Financial,		throughout their life cycle
		Compliance/		causing inaccurate records
		Legal,		for when tokens were created,
		Reputational		converted, updated, and retired
Transactional	Digital	Strategic,	TL-DT18	Digital Token development and	L, M, H
(Business)	Tokens	Operational,		change management process is
	(DT)	Financial,		not in place and followed, which
		Compliance/		may lead to unauthorized or
		Legal,		incorrect Digital Tokens being
		Reputational		introduced into the operational
				environment
Transactional	Digital	Strategic,	TL-DT19	Lack of a clearly defined Digital	L, M, H
(Business)	Tokens	Operational,		Token platform can potentially
	(DT)	Financial,		endanger the organization's
		Compliance/		transactional data or create
		Legal,		unauthorized operational
		Reputational		redundancies
Transactional	Digital	Strategic,	TL-DT20	Digital Token platforms are not	L, M, H
(Business)	Tokens	Operational,		configured with recovery
	(DT)	Financial,		procedures to recover loss of
		Compliance/		data and information
		Legal,
		Reputational	TL-DT21	Ownership of assets linked to	L, M, H
Transactional	Digital	Strategic,		Digital Tokens is not defined
(Business)	Tokens	Operational,		or managed by the organization
	(DT)	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT22	Data is not retained for DLT	L, M, H
(Business)	Tokens	Operational,		inputs, PKIs, or other critical
	(DT)	Financial,		systems; lack of availability
		Compliance/		limits backup and recovery
		Legal,		capability
		Reputational
Transactional	Digital	Strategic,	TL-DT23	Mechanisms are not in place	L, M, H
(Business)	Tokens	Operational,		or effective in ensuring Digital
	(DT)	Financial,		Token transactions are triggered
		Compliance/		as and if needed
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT24	Digital Tokens are not	L, M, H
(Business)	Tokens	Operational,		monitored to ensure tokens are
	(DT)	Financial,		utilized appropriately for
		Compliance/		authorized transactions or
		Legal,		operations
		Reputational
Transactional	Digital	Strategic,	TL-DT25	Digital Token ownership and	L, M, H
(Business)	Tokens	Operational,		management of ownership is
	(DT)	Financial,		not monitored appropriately
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT26	The DLT and off-chain ledger	L, M, H
(Business)	Tokens	Operational,		or accounting mechanisms
	(DT)	Financial,		are not monitored,
		Compliance/		compromising the ability to
		Legal,		accurately track usage of
		Reputational		tokens during normal
				operations and transactions
Transactional	Digital	Strategic,	TL-DT27	Monitoring mechanisms are	L, M, H
(Business)	Tokens	Operational,		not in place for Digital Tokens,
	(DT)	Financial,		which can create a risk of Digital
		Compliance/		Tokens being utilized, modified,
		Legal,		or changed by unauthorized
		Reputational		participants
Transactional	Digital	Strategic,	TL-DT28	Interfaces are not configured to	L, M, H
(Business)	Tokens	Operational,		ensure all process data
	(DT)	Financial,		transmissions within the
		Compliance/		blockchain are complete, accurate,
		Legal,		and secure
		Reputational
Transactional	Digital	Strategic,	TL-DT29	Interfaces are not configured to	L, M, H
(Business)	Tokens	Operational,		ensure all process data
	(DT)	Financial,		transmissions to off-chain
		Compliance/		platforms or systems are complete,
		Legal,		accurate, and secure
		Reputational
Transactional	Digital	Strategic,	TL-DT30	Without price fluctuation	L, M, H
(Business)	Tokens	Operational,		monitoring and defined response/
	(DT)	Financial,		action plan, tokens, contracts,
		Compliance/		tokens can be processed with
		Legal,		incorrect value at a given point
		Reputational		in time
Transactional	Digital	Strategic,	TL-DT31	Fluctuations in prices for	L, M, H
(Business)	Tokens	Operational,		commodity items like Digital
	(DT)	Financial,		Token storage create opportunities
		Compliance/		for sunk costs or deadweight loss
		Legal,		expenditures
		Reputational
Transactional	Digital	Strategic,	TL-DT32	The existence of digital tokens or	L, M, H
(Business)	Tokens	Operational,		funds used for blockchain
	(DT)	Financial,		transactions are not validated
		Compliance/
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DT33	Digital tokens are not configured	L, M, H
(Business)	Tokens	Operational,		with strong login credentials and
	(DT)	Financial,		account security protocols to
		Compliance/		restrict unauthorized access
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DW01	Privileged access is not	L, M, H
(Business)	Wallets	Operational,		appropriately restricted, logged,
	(DW)	Financial,		and monitored for Digital Wallets,
		Compliance/		which can lead to unauthorized
		Legal,		access to Digital Wallets
		Reputational
Transactional	Digital	Strategic,	TL-DW02	End-user access is not	L, M, H
(Business)	Wallets	Operational,		appropriately restricted, creating
	(DW)	Financial,		the risk of unauthorized changes/
		Compliance/		deployments/executions/updates/
		Legal,		modifications performed for
		Reputational		Digital Wallets and workflow
Transactional	Digital	Strategic,	TL-DW03	Digital Wallets are not configured	L, M, H
(Business)	Wallets	Operational,		with strong login credentials and
	(DW)	Financial,		account security protocols to
		Compliance/		restrict unauthorized access
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DW04	Digital Wallets, ledgers, and	L, M, H
(Business)	Wallets	Operational,		access points are stored in an
	(DW)	Financial,		insecure environment, and hot/
		Compliance/		warm/cold risk factors sy stemic
		Legal,		to each wallet platform are not
		Reputational		taken into account, creating
				greater risks to Digital Wallet
				operations and security of
				transaction data
Transactional	Digital	Strategic,	TL-DW05	Digital Wallet development	L, M, H
(Business)	Wallets	Operational,		and change management
	(DW)	Financial,		process is not in place and
		Compliance/		followed, which may lead to
		Legal,		inappropriate and incorrect
		Reputational		participants defined for the
				Digital Wallet
Transactional	Digital	Strategic,	TL-DW06	Digital Wallet development and	L, M, H
(Business)	Wallets	Operational,		change management process is
	(DW)	Financial,		not in place and followed, which
		Compliance/		may lead to unauthorized or
		Legal,		incorrect Digital Wallets being
		Reputational		introduced into the environment
Transactional	Digital	Strategic,	TL-DW07	Digital Wallet software is not	L, M, H
(Business)	Wallets	Operational,		updated in accordance w ith
	(DW)	Financial,		required updates, leading to
		Compliance/		version mismatching and
		Legal,		potential compromises to
		Reputational		security or operational limitations
Transactional	Digital	Strategic,	TL-DW08	Lack of a clearly defined Digital	L, M, H
(Business)	Wallets	Operational,		Wallet platform can potentially
	(DW)	Financial,		endanger the organization's
		Compliance/		transactional data, create
		Legal,		unauthorized operational
		Reputational		redundancies, or inhibit consistent
				and effective risk management of
				specific Digital Wallet platforms
				(i.e. software, hardware, ledger, etc.)
Transactional	Digital	Strategic,	TL-DW09	Digital Wallet platforms are not	L, M, H
(Business)	Wallets	Operational,		configured with recovery
	(DW)	Financial,		procedures to recover lost data
		Compliance/		and information
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DW10	Data is not retained for DLT	L, M, H
(Business)	Wallets	Operational,		inputs, PKIs, or other critical
	(DW)	Financial,		systems, lack of availability limits
		Compliance/		backup and recovery capability
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DW11	Input validation mechanisms for	L, M, H
(Business)	Wallets	Operational,		fields and records are not in place,
	(DW)	Financial,		which may compromise the
		Compliance/		Digital Wallet's operations
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DW12	Security mechanisms are not in	L, M, H
(Business)	Wallets	Operational,		place or effective in protecting
	(DW)	Financial,		output (data), creating the risk of
		Compliance/		unauthorized access or changes
		Legal,		made to output
		Reputational
Transactional	Digital	Strategic,	TL-DW13	Security mechanisms are not in	L, M, H
(Business)	Wallets	Operational,		place or effective in protecting
	(DW)	Financial,		Digital Wallets and their exposure
		Compliance/		to unauthorized parties via export
		Legal,		and sharing functionalities
		Reputational
Transactional	Digital	Strategic,	TL-DW14	Mechanisms are not in place or	L, M, H
(Business)	Wallets	Operational,		effective in ensuring Digital Wallet
	(DW)	Financial,		transactions are only triggered
		Compliance/		when appropriate and when needed
		Legal,
		Reputational
Transactional	Digital	Strategic,	TL-DW15	Mechanisms are not in place or	L, M, H
(Business)	Wallets	Operational,		effective in ensuring off-chain
	(DW)	Financial,		invoicing and billing is triggered
		Compliance/		and processed by authorized
		Legal,		participants appropriately as and
		Reputational		if needed
Transactional	Digital	Strategic,	TL-DW16	Mechanisms are not in place or	L, M, H
(Business)	Wallets	Operational,		effective in ensuring digital token
	(DW)	Financial,		transactions are triggered and
		Compliance/		processed appropriately as and
		Legal,		if needed
		Reputational
Transactional	Digital	Strategic,	TL-DW17	Mechanisms are not in place or	L, M, H
(Business)	Wallets	Operational,		effective in ensuring subsequent
	(DW)	Financial,		Digital Wallet transactions are
		Compliance/		triggered and processed by
		Legal,		authorized participants and
		Reputational		appropriately as and if needed
Transactional	Digital	Strategic,	TL-DW18	Monitoring meclianisms are not	L, M, H
(Business)	Wallets	Operational,		in place for Digital Wallets,
	(DW)	Financial,		which can lead to non-detection
		Compliance/		of Digital Wallets not
		Legal,		performing as intended in the
		Reputational		environment
Transactional	Digital	Strategic,	TL-DW19	Monitoring mechanisms are	L, M, H
(Business)	Wallets	Operational,		not in place for Digital Wallets,
	(DW)	Financial,		which can create a risk of
		Compliance/		impaired network performance
		Legal,		or latency
		Reputational
Transactional	Digital	Strategic,	TL-DW20	Mechanisms are not in place	L, M, H
(Business)	Wallets	Operational,		to monitor Digital Wallet
	(DW)	Financial,		transactions and ensure
		Compliance/		transactions are executed
		Legal,		per defined terms
		Reputational
Transactional	Digital	Strategic,	TL-DW21	Monitoring mechanisms are	L, M, H
(Business)	Wallets	Operational,		not in place for Digital Wallets,
	(DW)	Financial,		which can create a risk of the
		Compliance/		Digital Wallet not being retired
		Legal,		appropriately if necessary
		Reputational
Transactional	Digital	Strategic,	TL-DW22	Monitoring mechanisms are	L, M, H
(Business)	Wallets	Operational,		not in place for Digital Wallets,
	(DW)	Financial,		which can create a risk of the
		Compliance/		Digital Wallet being utilized,
		Legal,		modified, or changed by
		Reputational		unauthorized participants
Transactional	Digital	Strategic,	TL-DW23	Digital Wallet privacy is not	L, M, H
(Business)	Wallets	Operational,		maintained throughout the
	(DW)	Financial,		Digital Wallet lifecycle,
		Compliance/		creating the risk of private
		Legal,		information being divulged,
		Reputational		shared, or disseminated
Transactional	Digital	Strategic,	TL-DW24	Interfaces are not configured	L, M, H
(Business)	Wallets	Operational,		to ensure all process data
	(DW)	Financial,		transmissions within the
		Compliance/		blockchain are complete,
		Legal,		accurate, and secure
		Reputational
Transactional	Digital	Strategic,	TL-DW25	Interfaces are not configured	L, M, H
(Business)	Wallets	Operational,		to ensure all process data
	(DW)	Financial,		transmissions to off-chain
		Compliance/		platforms or systems are
		Legal,		complete, accurate, and secure
		Reputational
Transactional	Digital	Strategic,	TL-DW26	Mechanisms are not in place	L, M, H
(Business)	Wallets	Operational,		or effective in ensuring Digital
	(DW)	Financial,		Wallets are configured with
		Compliance/		appropriate transaction
		Legal,		thresholds to prevent failed
		Reputational		detection of transferred funds
Transactional	Digital	Strategic,	TL-DW27	Security mechanisms are not	L, M, H
(Business)	Wallets	Operational,		in place for Digital Wallets,
	(DW)	Financial,		compromising private keys or
		Compliance/		PKIs, which may result in
		Legal,		breaches of Digital Wallet
				security or risk of unauthorized
				access to assets stored on the
				wallet platform
Transactional	Digital	Strategic,	TL-DW28	The organization's legacy	L, M, H
(Business)	Wallets	Operational,		system accounts are not linked
	(DW)	Financial,		with PKIs or DLTs associated
		Compliance/		with the Digital Wallet, causing
		Legal,		lack of operational alignment
		Reputational		across the organization
Transactional	Clearing	Strategic,	TL-CS1	Movement of underlying asset	L, M, H
(Business)	and	Operational,		or currency is not synchronized
	Settle-	Financial,		with books of records.
	ment	Compliance/
		Legal,
		Reputational
Transactional	Buisness	Strategic,	TL-BU1	Transactions are not approved.	L, M, H
(Business)	Use case	Operational,
	transactions	Financial,
		Compliance/
		Legal,
		Reputational
Transactional	Buisness	Strategic,	TL-BU2	Transactions are not processed	L, M, H
(Business)	Use case	Operational,		accurately, completely or within
	transactions	Financial,		approved guidelines.
		Compliance/
		Legal,
		Reputational

TABLE 18

				In-scope/
				Out-of-
				Scope
				(TBD—As
Risk				per
Category	Domain	Control/Test Objective	Control Description	engagement)

Transactional	Smart	Control(s) is in place to ensure correct	Inquire management of the	In-scope
(Business)	Contracts	template is used for SC execution.	control activities that are
	(SC)		in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Smart	Control(s) is in place to ensure that required	Inquire management of the	In-scope
(Business)	Contracts	information or standard terms and conditions	control activities that are
	(SC)	are included in the SC before execution.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Smart	Control(s) is in place to ensure that required	Inquire management of the	In-scope
(Business)	Contracts	andcorrect participants associated with	control activities that are
	(SC)	the SC before execution.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Smart	Control(s) is in place to ensure that SC is	Inquire management of the	In-scope
(Business)	Contracts	reviewed, appraised, and approved by	control activities that are
	(SC)	appropriate participants.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Smart	Control(s) is in place to ensure that SC is	Inquire management of the	In-scope
(Business)	Contracts	executed after terms and conditions are	control activities that are
	(SC)	met by all participants.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Smart	Control(s) is in place to ensure that required	Inquire management of the	In-scope
(Business)	Contracts	events (e.g. invoicing, payments, change or	control activities that are
	(SC)	ownership) are initiated and completed	in place to meet applicable
		successfully during or after SC execution.	risks and relevant control
		Upon consensus, smart contracts auto-	objectives.
		matically executes the exchange of
		position and cash in a complete, accurate
		and timely manner.
Transactional	Digital	Control(s) is in place to ensure that DAs are	Inquire management of the	In-scope
(Business)	Assets	classified and created correctly and	control activities that are
	(DA)	successfully for transactional level	in place to meet applicable
		processing.	risks and relevant control
			objectives.
	Digital	Control(s) is in place to ensure that DA	Inquire management of the	In-scope
	Assets	ownership is transferred to the right/correct	control activities that are
	(DA)	participants in a timely manner.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that DA is	Inquire management of the	In-scope
(Business)	Assets	managed and maintained (e.g. classification,	control activities that are
	(DA)	valuation, and handovers) appropriately	in place to meet applicable
		throughout the lifecycle.	risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that DA is	Inquire management of the	In-scope
(Business)	Assets	retired appropriately at the end of the	control activities that are
	(DA)	lifecycle.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that valid	Inquire management of the	In-scope
(Business)	Currency	participants are on-boarded and assigned	control activities that are
	(DC)	with a digital wallet for DC transactions.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that a payor	Inquire management of the	In-scope
(Business)	Currency	account balance is checked and verified to	control activities that are
	(DC)	validate that sufficient DC is available before	in place to meet applicable
		the transaction is processed or completed.	risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that DC-in	Inquire management of the	In-scope
(Business)	Currency	(Cash-in) requests are processed completely	control activities that are
	(DC)	and accurately.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that DC-out	Inquire management of the	In-scope
(Business)	Currency	(Cash-out) requests are processed completely	control activities that are
	(DC)	and accurately.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that a	Inquire management of the	In-scope
(Business)	Currency	duplicate DC transactions are not processed.	control activities that are
	(DC)		in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that a DC	Inquire management of the	In-scope
(Business)	Currency	transactions are approved appropriately for	control activities that are
	(DC)	processing.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that a DC	Inquire management of the	In-scope
(Business)	Currency	transactions contain required information for	control activities that are
	(DC)	processing.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that a valid	Inquire management of the	In-scope
(Business)	Currency	unique address is generated and shared with	control activities that are
	(DC)	appropriate participants in safe and secure	in place to meet applicable
		manner for DC transactions processing.	risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that cancelled	Inquire management of the	In-scope
(Business)	Currency	and failed transactions are monitored,	control activities that are
	(DC)	processed and recorded in the books	in place to meet applicable
		accurately.	risks and relevant control
			objectives.
Transactional	Digital	Control(s) is in place to ensure that DC is	Inquire management of the	In-scope
(Business)	Currency	moved from one participant to the other (e.g.	control activities that are
	(DC)	payee and payor) correctly and in a timely	in place to meet applicable
		manner. Also, the movement of DC is	risks and relevant control
		recorded in the books of records accurately.	objectives.
Transactional	Digital	Control(s) is in place to ensure that DC is	Inquire management of the	In-scope
(Business)	Currency	evaluated correctly relative to underlying	control activities that are
	(DC)	asset or currency in a timely manner.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Clearing	Control(s) is in place to ensure that books	Inquire management of the	In-scope
(Business)	and	of records are updated when the underlying	control activities that are
	Settlement	asset or currency is processed. Reconcil-	in place to meet applicable
		iation and verification between books of	risks and relevant control
		records and underlying asset or currency	objectives.
		position is performed to validate
		integrity, accuracy and completeness of
		transactional and business information.
		Control(s) is in place to ensure that
		trades/transactions processing meet the
		following financial statements assertion
		requirements:
		1—Rights and obligations
		2—Completeness, accuracy, cutoff
		3—Existence
		4—Valuation
Transactional	Business	Control(s) is in place to ensure that business	Inquire management of the	In-scope
(Business)	Use case	transactions are authorized and executed in	control activities that are
	transactions	accordance with approved guidelines.	in place to meet applicable
			risks and relevant control
			objectives.
Transactional	Business	Control(s) is in place to ensure that trades/	Inquire management of the	In-scope
(Business)	Use case	transactions meet the following financial	control activities that are
	transactions	statements assertion requirements:	in place to meet applicable
		1—Rights and obligations	risks and relevant control
		2—Completeness, accuracy, cutoff	objectives.
		3—Existence
		4—Valuation

TABLE 19

				Re-
			Test Type	quest
Risk			(TBD—As	List
Category	Domain	Test Procedure (#)	per engagement)	(#)

Transactional	Smart	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Contracts	management regarding the control	observation, and/or
	(SC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Smart	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Contracts	management regarding the control	observation, and/or
	(SC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Smart	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Contracts	management regarding the control	observation, and/or
	(SC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Smart	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Contracts	management regarding the control	observation, and/or
	(SC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Smart	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Contracts	management regarding the control	observation, and/or
	(SC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Smart	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Contracts	management regarding the control	observation, and/or
	(SC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Assets	management regarding the control	observation, and/or
	(DA)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
	Digital	Based on the inquiry of the	Inquiry, Inspection,
	Assets	management regarding the control	observation, and/or
	(DA)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Assets	management regarding the control	observation, and/or
	(DA)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Assets	management regarding the control	observation, and/or
	(DA)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Digital	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Currency	management regarding the control	observation, and/or
	(DC)	activities in place assessment	Automated
		results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Clearing	Based on the inquiry of the	Inquiry, Inspection,
(Business)	and	management regarding the control	observation, and/or
	Settle-	activities in place assessment	Automated
	ment	results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Business	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Use case	management regarding the control	observation, and/or
	transac-	activities in place assessment	Automated
	tions	results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software
Transactional	Business	Based on the inquiry of the	Inquiry, Inspection,
(Business)	Use case	management regarding the control	observation, and/or
	transac-	activities in place assessment	Automated
	tions	results test procedures will be
		designed and data parameters will
		be identified to configure and
		operationalize the Blockchain
		Auditing software

In one or more embodiments, the blockchain risk framework is designed to produce testing procedures that align with a technology stack associated with a blockchain. FIG. 5A illustrates a correspondence between the testing procedures produced by a risk framework and a technology stack of a blockchain system according to examples of the disclosure. In FIG. 5A, a block chain use-case technology stack can include multiple technology stacks that are integrated together to form the overall blockchain computing system. For instance in the example of FIG. 6, a block-chain use-case technology stack 600 can include an application layer 502, encryption (cryptography) layer 506, a permissioned or unpermissioned network layer (i.e., operational layer) 508, a shared data layer 510, a commercial API layer 512, and an overlay network layer 514.
In one or more examples, an application layer 502 can include decentralized applications (i.e., a digital application or program) that can be run by many users or nodes on a decentralized network with consensus and other trustless protocols. They can be designed to avoid any single point of failure. The applications in the application layer provide workflow and processing logic to execute transactional activity using shared communications protocols and interface methods used by hosts in a communications network.
In one or more examples, an encryption (cryptography) layer 506 can include cryptography used to cipher (encrypt) and de-cipher (decrypt) information by using a mathematical function or algorithm. Encryption can refer to the process of transforming information so it is unintelligible/inaccessible/unreadable to anyone but the intended recipient. Decryption is the process of transforming encrypted information so that it is intelligible/accessible/readable again.
In one or more examples, a permissioned or unpermissioned network layer 508 can refer to both permissioned networks and unpermissioned networks. Unpermissioned networks can refer to an open blockchain network that anyone can join and participate in. The community operates and administers the blockchain, and one or more participants can provide consensus. Any user can join a permissionless network, i.e., exchanging digital currency on a public currency exchange. A permissioned network refers to a blockchain model that requires permission to join, read, write to, operate and administer. Multiple participants administer the blockchain under consortium or group leadership. There may be restrictions on how participants can contribute to the system state or consensus of transactions. In one or more examples network layer 508 can also include private blockchains. In a private blockchain, only a centralized entity or single participant has permission to write to the blockchain. Platform architects can decide how to assign permissions.
In one or more examples, shared data layer 510 can include organized collections of data that are stored and accessed electronically. In one or more example a commercial API layer 512 can include elements dealing with an interface in software that can act as a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans and combinations of these. Finally, in one or more examples, an overlay network layer 514 includes different types of LAN and WAN networks that are used to access the blockchain system. The network layer provides the means of transferring variable-length network packets from a source to a destination host via one or more networks.
One or more of the risk categories described above can correspond to one or more layers of the stack 500. For instance, in the example of FIG. 5A, transaction layer risks 518 can correspond to the application layer 502 of the stack 500. This can mean that test procedures created in response to the “transactional layer” risk framework can create test procedures that validate the application layer of the blockchain use-case stack 500. Likewise, blockchain architecture layer risks 514 can generate test procedures that test and validate the decentralized protocols layer 504, and the encryption layer 506. The operation layer risks 520 can generate tests that can validate and test permissioned network layer 508. Finally the infrastructure layer risks 516 of the risk framework can create test procedures that can validate and test shared data layer 510, commercial API layer 512, and overlay network 514.
FIG. 5B illustrates sub-categories corresponding to each risk framework category according to examples of the disclosure. As illustrated in FIG. 5B, each category of risk can include one or more subcategories. For instance, the governance and oversight risk category 530 can include one or more sub-categories including (but not limited to): business objectives, program sponsorship, leadership commitment, MIS and metrics, program management, operational and capital expenditure oversight, and project management. The cyber security risk category 530 can include one or more sub-categories including (but not limited to): cloud security, data security, data privacy, penetration testing, programming security, network security, patch vulnerability, threat detection, and threat response. The infrastructure risk category 534 can include one or more sub-categories including (but not limited to): servers and databases configuration, ITGCs, business continuity and disaster recovery, and IT asset management. The transactional layer risk category 536 can include one or more sub-categories including (but not limited to): smart contracts, digital assets, digital currency, cleaning and settlement, business use and case transactions. The operation layer risk category 538 can include one or more sub-categories including (but not limited to): permissioned network management, participant over boarding and off-boarding, application layer, blockchain consensus program management, and integration with off-blockchain systems and processes. Finally the blockchain architecture risk category 540 can include one or more sub-categories including (but not limited to): blockchain platform and protocol configuration, hardware security modules, signature management, cryptography, scalability, and availability.
In some embodiments, the results (i.e. testing procedures and parameters) of an assessment performed using the blockchain risk framework can be used to consolidate the audit and compliance activities into categories by nature of activity at the transaction layer and embed them into an validating software/tool. By drawing data from the underlying blockchain ledger as well as from other up and down stream systems affecting the use case, any and all necessary audit or assurance based procedures can be fully automate and active transparency for them on a real time basis (or some other cadence if preferred) can be provided to the practitioner.
As illustrated in the discussion above, the risk framework can provide a user interface that translates a user's blockchain auditing preferences into tangible tests and procedures that are then used to perform real-time continuous monitoring of the block chain system. FIG. 6 illustrates an exemplary process for generating blockchain test procedures according to examples of the disclosure. The process 600 described with respect to FIG. 6 can be performed on a computing system that includes a display and devices that are configured to accept input from a user such as a keyboard, touchpad, mouse, etc.
The process can begin at step 602, wherein the user is presented with the risk framework and is prompted by the risk framework to specify a risk level associated with each risk category and sub-category as described above. Once the user specifies the risk levels, the process can move to step 604 wherein the user can be presented with a series of controls of the blockchain that relate to the risks identified in step 602 (as described above). When presented with the series of controls, the user can then be prompted by the risk framework to input which controls are to be in-scope of the assessment, and which ones are to be considered out of scope as described above.
Once the user indicates which controls are in scope versus out of scope at step 604, the process can move to step 606, wherein the risk framework generates one or more test procedures based on the user's inputs into the risk framework. Once the tests are generated at step 606, the process can move to step 608 wherein the test procedures are transmitted to an external user. In one or more examples, transmitting the test procedures can include generating a planning file that can be used by a validation software (like the one described with respect to FIG. 4) to perform real-time and continuous validation of a blockchain.
FIG. 7 illustrates an example of a computing device in accordance with one embodiment. Device 700 can be a host computer connected to a network. Device 700 can be a client computer or a server. As shown in FIG. 7, device 700 can be any suitable type of microprocessor-based device, such as a personal computer, workstation, server, or handheld computing device (portable electronic device) such as a phone or tablet. The device can include, for example, one or more of processor 710, input device 720, output device 730, storage 740, and communication device 760. Input device 720 and output device 730 can generally correspond to those described above and can either be connectable or integrated with the computer.
Input device 720 can be any suitable device that provides input, such as a touch screen, keyboard or keypad, mouse, or voice-recognition device. Output device 730 can be any suitable device that provides output, such as a touch screen, haptics device, or speaker.
Storage 740 can be any suitable device that provides storage, such as an electrical, magnetic, or optical memory, including a RAM, cache, hard drive, or removable storage disk. Communication device 760 can include any suitable device capable of transmitting and receiving signals over a network, such as a network interface chip or device. The components of the computer can be connected in any suitable manner, such as via a physical bus or wirelessly.
Software 750, which can be stored in storage 740 and executed by processor 710, can include, for example, the programming that embodies the functionality of the present disclosure (e.g., as embodied in the devices as described above).
Software 750 can also be stored and/or transported within any non-transitory computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a computer-readable storage medium can be any medium, such as storage 740, that can contain or store programming for use by or in connection with an instruction execution system, apparatus, or device.
Software 750 can also be propagated within any transport medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a transport medium can be any medium that can communicate, propagate, or transport programming for use by or in connection with an instruction execution system, apparatus, or device. The transport readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, or infrared wired or wireless propagation medium.
Device 700 may be connected to a network, which can be any suitable type of interconnected communication system. The network can implement any suitable communications protocol and can be secured by any suitable security protocol. The network can comprise network links of any suitable arrangement that can implement the transmission and reception of network signals, such as wireless network connections, T1 or T3 lines, cable networks, DSL, or telephone lines.
Device 700 can implement any operating system suitable for operating on the network. Software 750 can be written in any suitable programming language, such as C, C++, Java, or Python. In various embodiments, application software embodying the functionality of the present disclosure can be deployed in different configurations, such as in a client/server arrangement or through a Web browser as a Web-based application or Web service, for example.
The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the techniques and their practical applications. Others skilled in the art are thereby enabled to best utilize the techniques and various embodiments with various modifications as are suited to the particular use contemplated.
Although the disclosure and examples have been fully described with reference to the accompanying figures, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the disclosure and examples as defined by the claims.
This application discloses several numerical ranges in the text and figures. The numerical ranges disclosed inherently support any rage or value within the disclosed numerical ranges, including the endpoints, even though a precise range limitation is not stated verbatim in the specification because this disclosure can be practiced throughout the disclosed numerical ranges.
The above description is presented to enable a person skilled in the art to make and use the disclosure and is provided in the context of a particular application and its requirements. Various modifications to the preferred embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the disclosure. Thus, this disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. Finally, the entire disclosure of the patents and publications referred in this application are hereby incorporated herein by reference.

Claims

What is claimed is:

1. A method comprising:

at an electronic device with a display and an interface configured to accept one or more inputs from a user of the electronic device:

displaying one or more risk categories to a user using the display;

prompting the user to input one or more risk levels via the interface, wherein each risk level on the one or more risk levels corresponds to the one or more risk categories displayed;

displaying one or more test objectives or controls via the display;

prompting the user to indicate which of the one or more test objectives are to be evaluated via the displaying; and

wherein in response to the user providing one or more risk levels and one or more test objectives, the electronic device is caused to:

convert the one or more user provided risk levels and one or more test objectives into one or more test procedures to be implemented by a real-time distributed ledger-based computing system validation tool; and

transmit the generated one or more test procedures to an external user.

2. The method of claim 1, wherein the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.

3. The method of claim 2, wherein if the user selects a transaction layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate an application layer of a distributed ledger-based computing system technology stack.

4. The method of claim 2, wherein if the user selects a blockchain architecture risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a decentralized protocols and encryption layer of a distributed ledger-based computing system technology stack.

5. The method of claim 2, wherein if the user selects an operational layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a permissioned network layer of a distributed ledger-based computing system technology stack.

6. The method of claim 2, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a shared data layer of a distributed ledger-based computing system technology stack.

7. The method of claim 6, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a commercial API layer of a distributed ledger-based computing system technology stack.

8. The method of claim 7, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate overlay network layer of a distributed ledger-based computing system technology stack.

9. The method of claim 1, wherein transmitting the generated one or more test procedures to an external user includes transmitting the generated one or more test procedures to a real-time continuous distributed ledger-based computing system auditing tool.

10. The method of claim 9, wherein transmitting the generated one or more test procedures includes writing the generated one or more test procedures to a planning file, and transmitting the planning file to the real-time continuous distributed ledger-based computing system auditing tool.

11. A computing system, comprising:

a display;

a user interface configured to receive inputs from a user of the system;

a memory;

one or more processors; and

one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs when executed by the one or more processors cause the processor to:

display one or more risk categories to a user using the display;

prompt the user to input one or more risk levels via the interface, wherein each risk level on the one or more risk levels corresponds to the one or more risk categories displayed;

display one or more test objectives or controls via the display;

prompt the user to indicate which of the one or more test objectives are to be evaluated via the displaying; and

wherein in response to the user providing one or more risk levels and one or more test objectives, the electronic processor is caused to:

transmit the generated one or more test procedures to an external user.

12. The computing system of claim 11, wherein the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.

13. The computing system of claim 12, wherein if the user selects a transaction layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate an application layer of a distributed ledger-based computing system technology stack.

14. The computing system of claim 12, wherein if the user selects a blockchain architecture risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a decentralized protocols and encryption layer of a distributed ledger-based computing system technology stack.

15. The computing system of claim 12, wherein if the user selects an operational layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a permissioned network layer of a distributed ledger-based computing system technology stack.

16. The computing system of claim 12, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a shared data layer of a distributed ledger-based computing system technology stack.

17. The computing system of claim 16, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a commercial API layer of a distributed ledger-based computing system technology stack.

18. The computing system of claim 17, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate overlay network layer of a distributed ledger-based computing system technology stack.

19. The computing system of claim 11, wherein transmitting the generated one or more test procedures to an external user includes transmitting the generated one or more test procedures to a real-time continuous distributed ledger-based computing system auditing tool.

20. The computing system of claim 19, wherein transmitting the generated one or more test procedures includes writing the generated one or more test procedures to a planning file, and transmitting the planning file to the real-time continuous distributed ledger-based computing system auditing tool.

21. A computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which, when executed by an electronic device with a display and a user input interface, cause the device to:

display one or more risk categories to a user using the display;

display one or more test objectives or controls via the display;

wherein in response to the user providing one or more risk levels and one or more test objectives, the device is caused to:

transmit the generated one or more test procedures to an external user.

22. The computer readable storage medium of claim 21, wherein the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.

23. The computer readable storage medium of claim 22, wherein if the user selects a transaction layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate an application layer of a distributed ledger-based computing system technology stack.

24. The computer readable storage medium of claim 22, wherein if the user selects a blockchain architecture risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a decentralized protocols and encryption layer of a distributed ledger-based computing system technology stack.

25. The computer readable storage medium of claim 22, wherein if the user selects an operational layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a permissioned network layer of a distributed ledger-based computing system technology stack.

26. The computer readable storage medium of claim 22, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a shared data layer of a distributed ledger-based computing system technology stack.

27. The c computer readable storage medium of claim 26, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a commercial API layer of a distributed ledger-based computing system technology stack.

28. The computer readable storage medium of claim 27, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate overlay network layer of a distributed ledger-based computing system technology stack.

29. The computer readable storage medium of claim 21, wherein transmitting the generated one or more test procedures to an external user includes transmitting the generated one or more test procedures to a real-time continuous distributed ledger-based computing system auditing tool.

30. The computer readable storage medium of claim 29, wherein transmitting the generated one or more test procedures includes writing the generated one or more test procedures to a planning file, and transmitting the planning file to the real-time continuous distributed ledger-based computing system auditing tool.