SYSTEM AND METHOD FOR VALIDATION OF DISTRIBUTED DATA STORAGE SYSTEMS

Information

  • Patent Application
  • 20190132350
  • Publication Number
    20190132350
  • Date Filed
    October 30, 2018
    6 years ago
  • Date Published
    May 02, 2019
    5 years ago
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
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
  • 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; andwherein 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; andtransmit 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; andone 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; andwherein in response to the user providing one or more risk levels and one or more test objectives, the electronic processor 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; andtransmit 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;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; andwherein in response to the user providing one or more risk levels and one or more test objectives, the 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; andtransmit 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.
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.

Provisional Applications (2)
Number Date Country
62579093 Oct 2017 US
62579095 Oct 2017 US