CROSS REFERENCE TO RELATED APPLICATIONS The present application which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/579,093, filed Oct. 30, 2017, and U.S. Provisional Patent Application Ser. No. 62/579,095, filed Oct. 30, 2017, each of which are incorporated herein by reference in their entirety and for all purposes.
FIELD OF THE DISCLOSURE The present disclosure relates generally to validation of distributed data storage systems, such as, for example, blockchain-based data storage systems.
BACKGROUND OF THE DISCLOSURE A distributed data storage (which may be referred to as a distributed database) system may include data storage devices that are not connected to a common processing unit, but are in different computing systems located at the same physical location or dispersed across one or more networks of interconnected computing systems at different physical locations. The data storage devices may communicate with each other via one or more wired or wireless communication networks. Typically, each of the data storage devices includes a copy of the stored data. Storing copies of the data in different data storage devices may eliminate a single point-of-failure and may induce both higher availability and increased reliability of the stored data.
Blockchain technology may be used to implement a distributed data storage system. In the blockchain technology, a system of networked nodes, e.g., computers or servers, each store a copy of the entire distributed data storage system. The blockchain-based distributed data storage system is often referred to as a blockchain. Whenever a group of data records is to be added to the distributed database, i.e., blockchain, each node may independently verify the group of data records in a batch process known as generating a block (also referred to as a data block). In the batch process, a node verifies the group of data records based on its copy of the blockchain storing previously verified data records. A node that generates the block may transmit the generated block to every other node in the system. In current implementations, only after the block has been verified by each node in the system may each node add the block to its copy of the blockchain. As each of the nodes independently verifies the block, blockchain technology may reduce the risk of a single point-of-attack or a single point-of-failure. Further, since a copy of the blockchain is maintained at each node, the data can be stored in a redundant manner.
A blockchain is a record of data activities. These data activities can be transactions in a distributed ledger, and/or any movement of money, goods, and/or secured or unsecured data involved, for example, in a purchase at a supermarket, in the creation and storage of a user's digital identification, in the assignment of a government ID number, in energy data exchange in the energy industry, in an e-voting service, or in the recording, tracking, and transferring of deeds and contractual agreements.
FIG. 1 illustrates a blockchain process flow in accordance with examples of the disclosure. The blockchain process flow 100 can begin at step 102, wherein a user/party can request to implement a transaction in the blockchain. Examples of transactions can be storing data such as a record to a distributed ledger. Once the request has been made at step 104, the transaction can be broadcast to other computers (known as nodes) in the network. At step 106, the network of nodes can then validate the transaction using a mutually a priori agreed upon algorithm. Once each node in the network of nodes validates the transaction, the process can move to step 108, wherein the verified transaction can be combined with other transactions (described in detail below) to create a new block of data for the ledger. Once the verified transaction has been combined, the process can move to step 110 wherein the new block can be added to the network's block chain. The new block can be added in such a way as to make it permanent and unalterable (i.e., through the use of cryptography). Once the new block has been added the process can move to step 112 wherein the transaction is completed.
As shown in FIG. 1, a blockchain needs to do two things: gather and order data into blocks, and then chain them together securely using cryptography. A blockchain is a decentralized ledger of all transactions in a network. Using blockchain technology, participants in the network can confirm transactions without the need for a trusted third-party intermediary.
FIG. 2 illustrates the process of generating a data block in a blockchain in accordance with examples of the disclosure. In the process 200, a piece of digital content (i.e., a new transaction represented in binary) can be received. Once received, the process can move to step 204 wherein a hash function is applied to the received transaction, so as to combine it with data from a pre-existing block in the blockchain. The output of the hash function can produce a fixed and smaller-in-length unique digital output. Hash algorithms can carefully designed to flow one-way making it impossible to determine the original digital content from the output once the hash algorithm is applied. Every new block in the blockchain may be linked with the hash function of the previous block to create a chain. At step 206, once the has function has been applied, an output can be generated. The output of the hash function can be a part of the data that is used in the creation of blocks, and these blocks can then cryptographically chained together at step 208. This process of creating blocks allows the blockchain system to prove that a file existed in a particular format at a given time without having to reveal the data in the file.
One of the benefits of blockchain is that every participant in the network has simultaneous access to a view of the information, thus allowing almost real-time data availability and transparency that can eliminate the need for reconciliation. Also, the integrity and security of the information on the blockchain are ensured with cryptographic functions that can prevent unwanted intrusion on the network from non-authenticated participants. In blockchain technology, verification can be achieved by participants confirming changes with one another, thus replacing the need for a third party to authorize transactions and providing a facility for peers in the network to validate updated information, thereby ensuring the validity and integrity of the data on the blockchain. Another benefit of blockchain includes the ability to run additional business logic; this means that agreement on the expected behavior of financial instruments can be embedded in the blockchain, which can facilitate the ability to design and implement shared workflow and enhance automation. Also, the ability to issue a digital currency or a digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units facilitates the ability to create and move assets without a trusted third party in the blockchain.
SUMMARY OF THE DISCLOSURE Blockchain presents a challenge to the traditional validation (also referred to as audit) approach, given there's no practical way to use point-in-time forensic analysis—the standard validation tool. Attempting to conduct a point-in-time forensic retrospective analysis can be ineffective and wildly inefficient. The conventional approach to auditing can negate one of the benefits of implementing blockchain in the first place: the promise of increased administrative efficiency. Also, the traditional validation approach can require the entire blockchain hash function to be reversed to obtain transparency of the digital content without breaking the chain or sequential order of the blocks. Such approach could cause significant technical complexities, challenges, and inefficiencies in the validation of a blockchain-based data storage system.
Increases in the volume of data activities and rapidly evolving complex technologies are creating a critical need for business, technology, and compliance functions to be prepared, adaptive, and agile to emerging challenges. Due to the increase in data activities, current validation methodologies that are manual, sample-based, and point-in-time do not provide the needed level of confidence. Validation methodologies need to shift from a manual to an automated and continuous approach to address a significant increase in data activities and emerging, complex new technologies. Current audit methodologies cannot provide the necessary assurance in areas where a blockchain is used.
Accordingly, there is a need for systems and methods to replace the conventional validation approach with a real-time validating process to build confidence and assurance in the blockchain technology. The concept behind real-time validating is to inspect data activities closer and closer to the point of occurrence. Real-time validating eliminates the concept of sampling in the conventional validating process. The purpose of sampling is to perform backwards-looking assessments of segments of populations to draw conclusions about the rest of the population. The embodiments described herein provide blockchain assurance-related baselines that eliminate the need for sampling in blockchain validating.
The type of validation and auditing required for a given a distributed ledger-based system such as blockchain can be user specific. No two organizations may need the same validation regime to audit its blockchain system. Often times, various risks and concerns may be important in one context, but not as critical in others. Therefore, there is a need to specify the types of tests that will be used based on a specific user/organization's risk priorities. The present disclosure thus provides a common risk framework that can allow for a user to conveniently determine what risks are important for it to manage. The risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization's blockchain system. The risk framework can thus be used to customize a software tool that can then be used to perform real-time validation of an organizations blockchain computing infrastructure and system.
In some embodiments, a validation tool/system for any given blockchain use case may include tools for monitoring and validating of data activities (also referred as transactions) in one or more data blocks of the blockchain, risk evaluation of the data activities, business and technical risk and reporting assessments, and software that enables transaction level assurance for operational processes running on any given blockchain use case. The continuous assurance, compliance, monitoring, and validating methodology may be a combination of services and software intended to provide transparency in meeting the assurance and compliance needs of stakeholders. In some embodiments, the continuous assurance, compliance, monitoring, and validating of blockchains may be based on an acceptance criteria. In some embodiments, the acceptance criteria may include evaluating the current state of a blockchain use case against different risk categories (e.g., six or more different risk categories) and across sub-categories (e.g., 100 or more different sub-categories) in order to address assurance and compliance needs of stakeholders. This evaluation may be performed by a risk evaluation system that is industry, use case and Blockchain platform agnostic.
In some embodiments, a method for validating a blockchain-based data storage system is provided. The method comprising: conducting a risk analysis of using the blockchain-based data storage system in a specified environment; generating a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determining a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; performing the validity test on the one or more data activities; and generating one or more validity test reports based on output of the validity test.
In some embodiments of the method, further comprising: displaying a user interface for selecting one or more test parameters of the validity test for testing compliance of the one or more data activities with the operating protocol of the blockchain-based data storage system; receiving from a user using the user interface one or more selections of the one or more validity test parameters based on the risk profile; and configuring the validity test based on the selection of the one or more validity test parameters.
In some embodiments of the method, the conducting the risk analysis comprises determining one or more risk categories of one or more risks involved in using the blockchain-based data storage system in a specified environment
In some embodiments of the method, the validity test is selected based on the risk categories.
In some embodiments of the method, the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.
In some embodiments of the method, the one or more data activities comprise storing one or more data in the data block.
In some embodiments of the method, the performing the validity test comprises performing the validity test continuously on the stored one or more data.
In some embodiments of the method, the generating the one or more validity test reports comprises: receiving from the user using the user interface a selection of one or more time periods within the one or more validity test; analyzing the output of the validity test during the one or more time periods; and generating the one or more validity test reports at end of each of the one or more time periods.
In some embodiments of the method, the performing the validity test comprises displaying, using the user interface, the output of the validity test; and wherein, in response to the output indicating that the one or more data activities failed the validity test, receiving from the user using the user interface a selection of whether the one or more data activities are exceptions to the operating protocol of the blockchain-based data storage system.
In some embodiments, a system comprising one or more processors and a memory comprising one or more programs, which when executed by the one or more processors, cause the one or more processors to: conduct a risk analysis of using the blockchain-based data storage system in a specified environment; generate a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determine a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; perform the validity test on the one or more data activities; and generate one or more validity test reports based on output of the validity test.
In some embodiments of the system, the one or more processors are further caused to: display a user interface for selecting one or more test parameters of the validity test for testing compliance of the one or more data activities with the operating protocol of the blockchain-based data storage system; receive from a user using the user interface one or more selections of the one or more validity test parameters based on the risk profile; and configure the validity test based on the selection of the one or more validity test parameters.
In some embodiments of the system, the one or more processors are caused to determine one or more risk categories of one or more risks involved in using the blockchain-based data storage system in a specified environment
In some embodiments of the system, the validity test is selected based on the risk categories.
In some embodiments of the system, the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.
In some embodiments of the system, the one or more data activities comprises storing one or more data in the data block.
In some embodiments of the system, the validity test is performed continuously on the stored one or more data.
In some embodiments of the system, the one or more processors are caused to: receive from the user using the user interface a selection of one or more time periods within the one or more validity test; analyze the output of the one or more validity tests during the one or more time periods; and generate the one or more validity test reports at end of each of the one or more time periods.
In some embodiments of the system, the one or more processors are caused to display, using the user interface, the output of the validity test; and wherein, in response to the output indicating that the one or more data activities failed the validity test, the one or more processors are caused to receive from the user using the user interface a selection of whether the one or more data activities are exceptions to the operating protocol of the blockchain-based data storage system.
In some embodiments, a non-transitory computer-readable storage medium storing one or more programs for validating a blockchain-based data storage system, the one or more programs configured to be executed by one or more processors and including instructions to: conduct a risk analysis of using the blockchain-based data storage system in a specified environment; generate a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determine a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; perform the validity test on the one or more data activities; and generate one or more validity test reports based on output of the validity test.
BRIEF DESCRIPTION OF THE FIGURES FIG. 1 illustrates a blockchain process flow in accordance with some embodiments.
FIG. 2 illustrates generation of a data block in a blockchain in accordance with some embodiments.
FIG. 3 illustrates shift in validating and control processes in distributed data storage systems in accordance with some embodiments.
FIG. 4 illustrates steps of a validation method for validating data activities in a data block of a blockchain data storage system in accordance with some embodiments.
FIG. 5A illustrates a correspondence of the risk framework testing procedures to a technology stack of a blockchain system according to examples of the disclosure.
FIG. 5B illustrates sub-categories corresponding to each risk framework category according to examples of the disclosure.
FIG. 6 illustrates an exemplary process for generating blockchain test procedures according to examples of the disclosure.
FIG. 7 illustrates an example of a computing device in according to examples of the disclosure.
Illustrative embodiments will now be described with reference to the accompanying drawings. In the drawings, like reference numerals generally indicate identical, functionally similar, and/or structurally similar elements.
DETAILED DESCRIPTION Embodiments of the present disclosure may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the present disclosure may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices, and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.
The embodiments described herein may be implemented within a local computer system. The computer system may be implemented in the contexts of the likes of computing systems, networks, servers, or combinations thereof. The computer system includes one or more processors and main memory. Main memory may store, in part, instructions and data for execution by processors. Main memory stores the executable code when in operation, in this example. The computer system may further include a mass data storage, a portable storage device, output devices, user input devices, a graphics display system, and/or peripheral devices.
The components of the computer system may be connected to a communication infrastructure (e.g., a bus or network). Processors and main memory may be connected via a local microprocessor bus, and the mass data storage, peripheral device(s), portable storage device, and graphics display system may be connected via one or more input/output (I/O) buses.
Mass data storage, which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor. Mass data storage may store the system software for implementing embodiments of the present disclosure for purposes of loading that software into main memory.
Portable storage device may operate in conjunction with a portable non-volatile storage medium, such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device, to input and output data and code to and from the computer system. The system software for implementing embodiments of the present disclosure may be stored on such a portable medium and input to the computer system via the portable storage device.
User input devices can provide a portion of a user interface. User input devices may include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. User input devices can also include a touchscreen. Suitable output devices include speakers, printers, network interfaces, and monitors.
Graphics display system may include a liquid crystal display (LCD) or other suitable display device. Graphics display system may be configurable to receive textual and graphical information and processes the information for output to the display device.
Peripheral devices may include any type of computer support device that adds additional functionality to the computer system.
The components provided in the computer system are those typically found in computer systems that may be suitable for use with embodiments of the present disclosure and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system can be a personal computer (PC), hand held computer system, telephone, mobile computer system, workstation, tablet, phablet, mobile phone, server, minicomputer, mainframe computer, wearable, or any other computer system. The computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID, IOS, CHROME, TIZEN, and other suitable operating systems.
The processing for various embodiments may be implemented in software that is cloud-based. In some embodiments, the computer system described above may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, the computer system may itself include a cloud-based computing environment, where the functionalities of the computer system are executed in a distributed fashion. Thus, the computer system, when configured as a computing cloud, may include pluralities of computing devices in various forms.
The cloud may be formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the computer system, with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers may manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be coupled with the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
While various embodiments have been described below, it should be understood that they have been presented by way of example only, and not limitation. The descriptions are not intended to limit the scope of the invention to the particular forms set forth herein. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the exemplary embodiments described herein. It should be understood that the description is illustrative and not restrictive. To the contrary, the present descriptions are intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims and otherwise appreciated by one of ordinary skill in the art.
Blockchain validation tool/system (may be referred as Blockchain Continuous Assurance, Compliance, Monitoring and Validating Solution or Blockchain Continuous Validating Solution) can include a Continuous Assurance, Compliance, Monitoring and Validating Methodology (may be referred as continuous validating methodology), Continuous Assurance, Compliance, Monitoring and Validating Criteria (may be referred as blockchain validating criteria or acceptance criteria), blockchain risk evaluation system (may be referred as blockchain risk framework), business and technical risk and reporting assessments, and software that enables transaction level assurance for any given Blockchain use case. The validation system can include a combination of services and software designed for practitioners to provide transparency in meeting the assurance and compliance needs of users of blockchain-based data storage systems.
FIG. 3 illustrates an exemplary process for deploying a distributed ledger validation tool according to examples of the disclosure. In the example of FIG. 3, the process 300 can begin at step 302 wherein the customer's (who will be using the validation system) blockchain use-case is analyzed. The use-case analysis performed at step 302 can include as an example, determining the type of blockchain that is being used by the customer, analyzing how the customer is using the block chain to effect transactions and what solutions the blockchain is meant to deliver to the customer.
Once a use-case analysis is completed at step 302, the process can move to step 304, wherein a risk framework analysis is applied to the customer blockchain. A risk framework is a tool that can be used by stakeholders or auditors to assess and define the assurance and compliance needs of a particular blockchain use-case. The framework can allow the user to step through a series of categories of risks (i.e., risks to an organization engendered by their use of blockchain) to determine what risks they wish to audit for, and to determine the extent to which those risks would harm the organization. The risk framework described above can be industry, use-case, and blockchain technology agnostic so that practitioners across all industries and sectors can use to address the risk assurance and compliance needs independent of the Blockchain technology variant and use case.
Practitioners can use the risk framework as a standard approach and framework to evaluate the current state of a Blockchain use case which can be inclusive of upstream and downstream (on-Blockchain and off-Blockchain) processes, technologies, and underlying data elements (people, processes, technologies) against 6 different risk categories, applicable domains, and 100+ sub-risk categories in order to address assurance and compliance needs (risks, control objectives, controls, testing objectives and procedures, and reporting parameters) of the following stakeholders simultaneously or exclusively. The risk categories, domains and sub-risk categories can be used exclusively or mutually exclusively to determine targeted and/or upstream and downstream impacts. These parameters can be used to customize and personalize an assurance or auditing software/tool to achieve required level of assurance and compliance as by-product of processed transactions.
In one or more examples, the risk framework can include such categories as: governance and oversight of the blockchain, cybersecurity issues with the blockchain, infrastructure risks, blockchain architecture risks, operational risks, and transactional risks. As part of using the risk framework, a user can (via user interface) go over each risk category and the sub-categories within each risk category and indicate which risks are pertinent to their organization (or that they wish to be analyzed), and also indicate the degree and scope of those risks using the risk framework.
Once a user has engaged the risk framework at step 304 to identify the risks they want analyzed during an audit, the process can move to step 306 wherein the user-preferences supplied to the risk framework can be converted in to one or more testing procedures to be performed during the real-time compliance testing of the customer's blockchain. As will be described in further detail below, the testing procedures can then be used by the validation/auditing software to in real-time audit the blockchain.
Once the results from the risk framework are converted to testing procedures at step 306, the process can move to step 308, wherein the real-time auditing tool is customized using the results gleaned from the risk framework. In one or more examples, customizing the auditing tool can include setting up one or more testing procedures that the tool will engage in during its operation, and also setting up the formatting of the reports that the tool will ultimately produce for review by the customer (described in further detail below).
Finally, once the tool has been customized per based on the assessment of the use-case established at step 302 and the application of the risk framework at step 304, the process can move to step 310 wherein the tool is deployed in the customer environment. As will be described in further detail below, deploying the tool can refer to the creation of a validation node that becomes part of the customer blockchain environment. The validation node can be a read only node that includes the software to run the test procedures discussed with respect to step 306 on blockchain transactions as they occur in real time in the customer environment.
In one or more embodiments, the validation system created by the process described with respect to FIG. 3, may utilize a permanent planning file that can contain the details and results of the risk framework application, that can then be used at step 306 to convert the risk framework results into testing procedures. In other embodiments, the permanent planning file can instead be directly created by a user without the need to engage in the risk framework analysis above.
In some embodiments, the above set of activities of the validating methodology may be executed systematically (e.g., via software, hardware, or a combination thereof) with manual input by the auditor or compliance practitioner. In one or more examples, the validating methodology described above with respect to steps 302 may be divided into three phases (e.g., planning, fieldwork, and reporting sprints). The three phases are described below.
Planning Phase: In some embodiments, steps 302, 304, and 306 of FIG. 3 may constitute the planning phase. During the planning phase, an assessment is performed to identify validating test procedures using blockchain validating criteria and risk framework. In order to provide a required level of assurance for any given blockchain use case, a standardized acceptance criterion is developed to capture inputs and outputs and set the right assurance threshold level based on stakeholders' requirements, as needed. A blockchain risk framework can be used to identify inputs and define outputs in order to create the required level of assurance. Based on the assessment results obtained from using the criteria and risk framework of step 304, validity test and reporting parameters are determined (at step 306).
Fieldwork Phase: In some embodiments, step 308 and 310 of FIG. 3 may constitute the fieldwork phase. During the fieldwork phase, the validating software may be customized with the test and reporting parameters determined in the planning phase. Once the customized software is deployed at step 310, transactional information can be captured based on the defined data parameters and passed through a rules engine (described in further detail below), which can host the validity test rules. Practitioner uses the validity software to execute real-time evidence gathering and testing across a data activities—level data population set on a real-time basis (or some other interval if preferred, e.g., bi-monthly or monthly).
As will be described in further detail below, the software can classify testing results as either an observation (visual or virtual alert) when the rule breaks/fails, or a no-observation if the transaction passes the test rule with no breaks/fails. A practitioner classifies an observation as either an exception/deviation noted, or no exception/deviation noted. Further, the practitioner raises exception(s)/deviation(s) noted per test procedure as an issue, including exception/deviation details, investigation results, issue summaries and details, impact rankings and details, and management action plan details.
Reporting Phase: In some embodiments, step 310 of FIG. 3 may constitute the reporting phase. Once the validity tests and other fieldwork activities (i.e., exceptions/deviations and issues) are complete, the deployed tool can produce an issue and interim audit report, including ratings and details at the process and subprocess levels to achieve continuous reporting and monitoring (or some other interval if preferred, e.g., bi-monthly or monthly. In some embodiments, after the interim reporting cycle for the quarter (or some other interval if preferred) is complete, practitioner produces and issues a quarterly audit report including ratings and opinions at the process and subprocess levels to the stakeholders.
The testing and reporting can provide the required assurance level information at the process and subprocess levels based on the applicable risks, controls, testing objectives, and reporting parameters across the entire population data set to address stakeholders' needs.
In some embodiments, the exception can be replaced with the deviation in the flow described above to address the process and functional needs of the stakeholders in compliance or non-compliance areas (outside of audit).
In some embodiments, the validating methodology provides a practitioner with an end-to-end standardized audit process and sets of activities that can be used to obtain real-time transparency around given business processes (i.e., non-blockchain and blockchain) and provide compliance and audit-type reporting automatically or manually. In some embodiments, the methodology enables the practitioner to execute set of audit and compliance activities by the computer in a continuous fashion, which can bring a significant increase in efficiency and effectiveness, achieving a higher/maximum level of confidence.
In some embodiments, the blockchain validation tool/system is designed and developed to provide real-time transaction-level assurance with immediate results across a full population data set, which can be used by stakeholders and end-users simultaneously or exclusively to address their assurance, audit, and/or compliance needs. Some examples of stakeholders would be such personnel as the head of innovation, head of corporate development, chief technology officer, head of business segment(s), and chief audit executive. Some examples of end-users would be internal users (e.g., operations (first line of defense), enterprise risk management (second line of defense), internal audit (third line of defense), and tax); and external users (e.g., legal and regulatory).
Some assumptions in performing real-time assurance may include that: (1) off-chain data (i.e., data not stored within the blockchain) exists and may be required for key assurance reporting; (2) ordering, integrity, and completeness of data activities in a blockchain can be critical to assurance; (3) while the integrity of blockchain data can be validated, third-party “off-chain” data is not immutable and subject to change; and (4) assurance is being conducted on the qualitative and quantitative data activities of the blockchain, rather than the technical blockchain implementation (consensus protocols, block formation rules, blockchain forks, etc.).
The blockchain validation system may include major five components: (1) customer environment 404, (2) integration unit 406, (3) data block service unit 408, (4) front-end service or reporting unit 410, and (5) interfaces 412. In addition, the system 400 may interface with third-party computing systems (as indicated by block 402) as well as the customer blockchain 404. The following sections discuss these architectural components of the blockchain validation system (which may be referred to as the blockchain assurance and validation solution, blockchain assurance and validating software, or blockchain assurance solution).
FIG. 4 illustrates an exemplary blockchain validation system according to examples of the disclosure. The following discussion with reference to FIG. 4 outlines a structure to establish a validation node capable of performing real-time assurance off third-party blockchains. The validation system consists of individual microservices performing discrete pieces of functionality, which, when holistically viewed, can enable real-time assurance and validation of data activities in data blocks of blockchains in a blockchain network. The blockchain network may have a plurality of blockchain nodes having blockchain-based data storage systems in each blockchain node as described above with respect to FIG. 1. In some embodiments, the blockchain network and the blockchain node of FIG. 4 may be represented by the network and nodes shown in FIG. 1. The discussion below provides insight into the primary responsibilities of each service as a new blockchain event or data block is added to a node in the blockchain network.
Some assumptions in performing real-time assurance may include that: (1) off-chain data (i.e., data not stored within the blockchain) exists and may be required for key assurance reporting; (2) ordering, integrity, and completeness of data activities in a blockchain can be critical to assurance; (3) while the integrity of blockchain data can be validated, third-party “off-chain” data is not immutable and subject to change; and (4) assurance is being conducted on the qualitative and quantitative data activities of the blockchain, rather than the technical blockchain implementation (consensus protocols, block formation rules, blockchain forks, etc.).
The blockchain validation system may include major five components: (1) customer environment 404, (2) integration unit 406, (3) data block service unit 408, (4) front-end service or reporting unit 410, and (5) interfaces 412. In addition, the system 400 may interface with third-party computing systems (as indicated by block 402) as well as the customer blockchain 404. The following sections discuss these architectural components of the blockchain validation system (which may be referred to as the blockchain assurance and validation solution, blockchain assurance and validating software, or blockchain assurance solution) with reference to FIG. 4.
To illustrate the functionality of the components contained within system 400, a description of the data flow in the architecture of FIG. 4 can be pertinent. The process of validating blockchain transaction can begin with the addition of a new data block from one of the blockchain nodes 418 residing in the customer's blockchain environment. When a node 418 attempts to introduce new data into the blockchain, that activity can be sent to chain listener 422. The chain listener can serve as the initial integration point between the blockchain assurance and validation tool, and the customer blockchain. The goals of the chain listener can be to emit transactional blockchain events occurring within the blockchain. In most cases, blockchains provide varying levels of “feed” data in instances where generic events or transactions are published to subscribers of its services; in these cases, the chain listener can leverage those existing services to provide events for downstream service consumers.
Events trigger the initial action that results in a transaction or data activity (or the addition of a block) within the blockchain. Events should trigger one or more transactions within the blockchain, indicating that some key information should be delivered across the blockchain network. These transactions will manifest as a simple key-value pair, as illustrated below:
{
//on the blockchain
_id: 3199444, //a unique identifier
dateTime: 2103323223 //unix timestamp,
transaction; 2193298439843984381212211 //a transaction,
sender: John Doe, //string
receiver: Jane Doe, //string
amount: 10 //integer
}
In most industry use-cases, blockchains will not actually store transactional data. The use of a shared ledger implies the likely scenario in which sensitive-data transactions occur. Moreover, storage costs can escalate, and blockchains are not intended to store items such as images, documents, etc. As such, an event transaction may have a simple encrypted “hash,” which can contain a secret location that can be unencrypted by the asset owner. The same object described above can easily be represented as such:
{
// on the blockchain
_id: 3199444, //a unique identifier
dateTime: 2103323223 //unix timestamp,
hash; 2193298439843984381212211 //an encrypted value that could
represent anything
}
{
// off the blockchain (such as in a relational database).
_id:2193298439843984381212211,
transaction; 2193298439843984381212211 //a transaction,
sender: John Doe, //string
receiver: Jane Doe, //string
amount: 10 //integer
}
A “push” feed (built within the blockchain protocol) is the ideal setup, because it properly segregates the responsibilities across the blockchain network and the assessment and validating software. As such, it is up to the blockchain to provide guarantees that ensure transactions are emitted while the chain listener is responsible for relaying those events into the validation system. If this service is ever stopped or interrupted, it should possess enough awareness and understanding to resume starting with its last acknowledged transaction. This ensures that transactions are not “duplicated” within the environment and that unnecessary work to “reprocess” blockchain transactions will not occur.
Thus, once the chain listener detects that a new transaction is occurring on the blockchain, it can tag the event and send them to event listener 442 by placing the events onto a queue 434. The event listener 442 may then pick up the new data block from queue 434 and perform a series of tasks with the new data block acquired from queue 434. In one or more examples, the event listener 442 may store a copy of the new data block by storing in event store 436. The event store 436 can be the principal “record of truth” that represents a historical copy of the blockchain from which all downstream systems derive their system state. Records that live as unstructured data, and events transacted from the blockchain listener, will live as JSON objects within this document store (e.g., MongoDB), and will live in its nearest representation to data on the blockchain. The primary goals of the event store can be twofold: (1) separating querying and data, extraction responsibilities from the validation node (to avoid directly querying the blockchain for events); and (2) creating a consistent storage abstraction that can be leveraged regardless of the blockchain platform.
The event store can also enable additional capabilities such as data “snapshots,” where events or transactions can be “replayed” as they occur. The event log provides a strong audit capability (e.g., accounting transactions are an event source for account balances) where historic states can be recreated by replaying past events.
Simultaneously to storing the event at event store 436, the event listener 442 can transmit the new data block to data enricher 424 by placing it into a queue 432. The data enricher 424 can take the data block stored at queue 432 and request information from external data sources (e.g., from a customer or third party) through the off-chain API 426 that collects third-party data stored at 414, and off-chain data stored at 416. External data sources can be centrally managed through the use of an off-chain API 426 that can federate requests to one or many external data sources such as third party data 414 or off-chain data 416. External data sources are centrally managed through the off-chain API 426, which federates requests to one or many external data sources. Off-chain data (sometimes referred to as oracles) provide, contextual information about blockchain data, including real-time data elements (e.g., stock prices), personally identifiable or sensitive information (e.g., names or addresses), or extraneous metadata, which could bloat the size of the blockchain ledger. Through the creation of its own independent service, the application reduces the tight coupling between internal and external application logic, and limits exposure to third-party systems.
Customer environment 404 which can store off-chain data 416, as well as third party data coming from data store 414 can describe the spectrum of tasks occurring within third-party networks and the original inception of the transaction, data activities, or data block onto the blockchain-based data storage system. While upstream (i.e., actions prior to hitting the blockchain) activities should be considered “out of scope” of the tool 400—need for assurance can require that examination occurs as close to the original “source of truth” as possible—it can therefore be essential for critical data elements or keys to exist within the blockchain, or else they will not be captured by the downstream processes. Careful design of blockchain metadata is needed to enable the ability for assurance and validation. Thus, customer environment 404 can collect and store various “off-chain” data at data store 416.
As an example of off-chain data, if a distributed ledger is storing emails being sent back and forth from the customer, the names associated with each email address could be an example of “off-chain data” that could be used to help validate and audit the blockchain itself. Thus, the type of data that while not needed for action block creation itself, may be needed to validate transactions occurring in real-time can be stored at data store 416. Off-chain storage contains data that is not readily available for public consumption. Off-chain storage may reference anything from trade data to vendor/sales information, or anything that provides context to the transactions inscribed on the block.
While blockchain data is historic and immutable, off-chain data is not immutable or immune to tampering. This makes logical sense: off-chain data will likely be sensitive, business-contextual data and will often be used by multiple consumers within an organization. The duplication of data across off-chain and on-chain data which poses consistency issues and the two are in-sync. It is possible that records reflected within the blockchain are not represented off-chain. Downstream processes will need to reflect this known hazard when they are working with off-chain data by properly rebuilding or reconstructing records that require updates to ensure the audit solution accurately reflects the historic state.
Once the data enricher 424 adds in the off-chain data, it can then transmit the augmented even to rules engine 428 via queue 430. Customer-specific business assurance rules can applied to the data block in the rules engine 424. Rules can be highly specific to the business and industry concerned and be customized according to each customer as described above with respect to the risk framework. Rules can the cornerstone of the validation solution, providing the basis of when/why transactions violate specified conditions.
The rules engine 428 can be implemented as a worker with a specified set of instructions on how to apply rules against transactions. Because the user interface also relies on the awareness and knowledge of rules, the rules engine can retrieve the latest inventory of rules from a shared database (not pictured). While this extra network request may seem unnecessary, it also can enable user-features such as the dynamic toggling of rules, the addition/subtraction of rules without hard resets, etc.
Two categories of rules may be applied to transactions or data activities in the blockchain: streaming rules that assess against individual transactions, and batch rules that assess against an aggregate of transactions.
Streaming Rules: Incoming transactions can be evaluated against a set of one or many business rules that can assess validity across a variety of dimensions (e.g., completeness of a transaction, blacklisting of specific values, application of transaction logic such as input=output, etc.).
Batch Rules: Incoming transactions that possess some relationship to historical or past events can leverage the event store to identify patterns that may violate assurance rules (e.g., aging transactions, number of transactions from an account, etc.).
These rules are generators of “observations” within the solution. Observations indicate the violation of a pre-defined guideline set by business or assurance rules, which Users of the system will evaluate within the web interface. As will be described in detail below, the observations can be collected and presented to a user, who can then review each observation and determine whether the observation warrants further scrutiny.
Once the rules engine 428 applies the one or more rules to the data block, the results of the tests performed by the rules engine can be sent to reporting database 444. Reporting database can store the results of the application of the rules to the data block.
The reporting DB is the final staging area where business-oriented data structures can be queried and analyzed. Any blockchain transaction saved within the event store will create one or many transactions within the reporting DB; this will allow a variety of views to be “staged” and immediately ready for analytics, assurance reports, etc.
In order to create this reporting state for user interfaces, any off-chain data must be already “enriched” and co-located with other blockchain events. The integration of off-chain and on-chain data will require a high degree of collaboration and integration between the third party and the tool.
Reliability and uptime of external systems can be unpredictable, and the present invention anticipates “offline” scenarios where external systems are unavailable. Moreover, the current state of the reporting DB can be off-sync with its original source of truth if records have been updated within the host system.
To resolve these issues, the architecture should incorporate several precautionary measures to ensure the reporting DB is in an accurate representation of its source of truth. In the “offline” scenario, worker jobs should fail, persist, and retry to ensure transactions are not lost. Additionally, periodic background validation jobs should have the ability to check the accuracy and updates of records. This integration has the potential to be complex, depending on the auditability and traceability of third-party systems.
The results stored in reporting database 444 can be sent to user interface 412 for further evaluation via reporting API 448. The reporting platform will be the sole interface through which users interact and communicate with blockchain data. A separate “reporting API” provides external users with access into data that has already been relayed, saved, and transformed into contextual and relevant pieces of information. This information is ready to be consumed by the web interface, which enables risk assurance professionals to make decisions according to real-time events on the blockchain.
The user interface presents the results of the test procedures to the rules engine. The user interface may be a web page, a web dashboard, a mobile device, or any other device that is configured to display or output the validation report.
Referring back to FIG. 3, at step 304 a risk framework can be used to generate one or more tests. Those tests can then be transmitted to rules engine 428 in the system described in FIG. 4 to perform real-time and continuous validation of a blockchain system. The risk framework can allow for a user to specify the risks they wish to monitor for during their testing and the level of assurance they are seeking, and those inputs can be converted into a plurality tests that are run during the operation of the blockchain. Thus, while all users of the validation tool can be presented with a common risk framework, the output of the risk framework can be specific to each individual user/organization to ultimately generate a unique validation tool that addresses the specific needs of the organization.
The discussion below can illustrate how the risk framework described above can fit in with an overall approach to risk management for validating a blockchain system.
In some embodiments, determining the acceptance criteria (may be referred to as assurance threshold formula) may include the five steps discussed below.
1—Purpose (P1)—Gain an understanding of the blockchain use case, business purpose, and the resultant effect on the risks and control objectives.
2—Process (P2)—Assess on and off blockchain processes and technologies to understand continuous assurance methodology affects, up and downstream, on audit expectations and the entire process risk profile.
3—Risks (Rs)—Assess the blockchain architecture variant and identify applicable control objectives using the blockchain risk framework.
4—Stakeholder (Sr)—Identify assurance related stakeholders, determine and inventory their expectations and needs for reporting purposes.
5—Assurance Threshold Formula (ATx)—Total number of test procedures required to achieve the required level of assurance. The test procedures can be coded into the rule engine of the audit software/tool for automated testing and transaction level assurance.
Based on the results obtained from these four activities in combination of the blockchain risk framework, the following Assurance Threshold Formula (ATx) is determined:
P1+P2+Rs+Sr=ATx
The solution sum of Y (Continuous Audit) must always be equal or greater than ATx in order to create the necessary level of assurance. Therefore Y ATx.
As shown above, the risk framework (step 3) can work to provide a required level of assurance to a customer that their blockchain system is operating with minimal risk.
In some embodiments, the blockchain risk evaluation system or risk framework may assess the current state of a blockchain use case against different risk categories (e.g., six or more different risk categories) and across sub-categories (e.g., 100 or more different sub-categories) in order to address assurance and compliance needs of stakeholders. This assessment may be performed by a risk evaluation system that is industry, use case and Blockchain platform agnostic. In some embodiments, the results of these assessments provide the necessary information to identify applicable risks, control objectives, testing reporting and reporting parameters that are used to customize our the continuous validating software.
The blockchain risk framework is a component of the blockchain continuous validating solution. Due to availability and use of several variants of blockchain technology for use cases and lack of a standard approach or risk frameworks that can be used to obtain required level of transparency for a given blockchain use to meet compliance, assurance, and audit requirements, an approach has been designed and the supporting framework is developed that is industry, use case and blockchain technology variant agnostic so that practitioners across all industries and sectors can use to address the risk assurance and compliance needs independent of the blockchain technology variant and use case.
Practitioners can use blockchain risk evaluation system as a standard approach and framework to evaluate the current state of a Blockchain use case which can be inclusive of upstream and downstream (on-Blockchain and off-Blockchain) processes, technologies, and underlying data elements (people, processes, technologies) against 6 different risk categories, applicable domains, and 100+ sub-risk categories in order to address assurance and compliance needs (risks, control objectives, controls, testing objectives and procedures, and reporting parameters) of the following stakeholders simultaneously or exclusively. The risk categories, domains and sub-risk categories can be used exclusively or mutually exclusively to determine targeted and/or upstream and downstream impacts. These parameters can be used to customize and personalize an assurance or validating software/tool to achieve required level of assurance and compliance as by-product of processed transactions.
Some examples of stakeholders provided below:
-
- Chief Executive Officer
- Chief Financial Officer
- Chief Technology Officer
- Chief Information Security Officer
- Chief Audit Executive (3rd Line of defense)
- Head of Enterprise Risk Management (2nd line of defense)
- Head of Operations (1st line of defense)
- Head of Innovation
- Head of Corporate Development
- Head of Compliance and legal
- Head of Tax
- External Regulators
- Head of Business Segment(s)
Risk Categories:
In Some Embodiments, Some Examples of Risk Categories and their relevant domains are provided in Table 1.
TABLE 1
Risk Category Domain
Governance and Business Objectives
Oversight Program Sponsorship
Leadership Commitment
MIS and Metrics
Program Management
Operational and Capital Expenditure Oversight
Project Management
Third-party Risk
Cyber Security Cloud Security
Data Security
Data Privacy
Penetration Testing
Programming Security
Network Security
Patch and vulnerability
Threat detection
Threat response
Infrastructure Layer Servers and Databases Configuration
ITGCs
Business Continuity and Disaster Recovery
IT Asset Management
Architecture Layer Blockchain Platform & Protocol Configuration
Hardware Security Modules
Signature Management
Cryptography
Scalability
Availability
Operational Layer Permissioned network management
Participant Onboarding and Off-boarding
Application layer
Blockchain consensus program management
Integration with off-Blockchain systems and
processes
Transactional Layer Smart Contracts
Digital Assets
Digital Currency
Clearing and settlement
Business Use Case Transactions
The sub-risk categories, control and testing objectives, test procedures and request lists for each for the above risk categories and domains of Table 1 are provided below. When engaging with the risk framework, a user using a computer/laptop or some other computing device, can be guided through each risk category and specify parameters relating to the category. In one or more examples, the user can specify if a particular risk is to be classified as low, medium, or high. In one or more examples, the categories, low, medium, high, can change for one risk, from one blockchain system to another. As an example, because there may be other surrounding controls in place or there may be some compensating controls in place, a particular risk may be categorized as low. Alternatively another in another blockchain environment, a user may assess that risk to be high because the system doesn't have certain compensating controls in place or certain processes or technology or checks and balances in place. In such a system the risk maybe categorized as high. Thus classifying a risk as low, medium, high, can mean that there's a possibility that this can fall into either of these three categories, depending on the use case and depending on the environment, that is being examined.
In some embodiments, governance and oversight risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain portfolio and program management, governance, and oversight. Focus areas for this category includes blockchain strategy, research and development, investment, business, operations, product and use case solution development activities.
The sub-risk categories, control and testing objectives, test procedures and request lists for Governance and Oversight risk category are provided below in Tables 2-4. Table 2, is an exemplary sub-risk category table for the governance and oversight risk category. The table below can be presented to a user accessing the risk framework from a computing device configured to receive inputs from a user. The table below can include a risk category indicator that specifies the category of risk as defined above. Each of the Risk Categories cover Blockchain including upstream and downstream processes, technologies stacks, and people and associated risk profiles.
The table below can include a domain column can identify the areas relevant to the blockchain that is covered by each risk category. In one or more examples, the table below can include a risk classification column that identifies the applicable processes and technologies within each domain, where the risk is present. In one or more examples, the table below can also include a risk number that simply provides a method for identifying the risk in numerical form. In one or more examples, the table below can also include a risk description that describes the risk applicable to/associated with the processes and technologies within each domain. In one or more examples, and as described above, the table can also include a risk level rating (low, medium, high) as described above.
When the user is presented with the framework, they can initially review each risk category, and specify whether such a risk is a low, medium, or high concern. Presented below is an example risk table for the government and oversight risk category.
TABLE 2
Risk Level (L,
M, H)
Risk Risk (As
Risk Category Domain Classification Number Risk Description applicable)
Governance Business Strategic, GO-BO1 At the senior management level, L, M, H
and Oversight Objectives Operational, business objectives and justification is
Financial, not clearly defined leading to failure
Compliance, of program and misalignment with
Legal, or strategy and overarching governance
Reputational framework.
Governance Business Strategic, GO-BO2 The Blockchain Program is L, M, H
and Oversight Objectives Operational, implemented in silos without a formal
Financial, oversight committee resulting in
Compliance, inefficient utilization and duplication
Legal, or of efforts.
Reputational
Governance Business Strategic, GO-BO3 Unapproved or miscommunicated L, M, H
and Oversight Objectives Operational, scope can lead to failure of program or
Financial, poor utilization of program resources.
Compliance,
Legal, or
Reputational
Governance Program Strategic, GO-PS1 Lack of involvement from Senior L, M, H
and Oversight Sponsorship Operational, Management can lead to low
Financial, organizational awareness and failure
Compliance, of the Blockchain program.
Legal, or
Reputational
Governance Program Strategic, GO-PM1 Failure to define and monitor Key L, M, H
and Oversight Management Operational, Performance Indicators (KPIs) may
Financial, lead to failure of the program.
Compliance,
Legal, or
Reputational
Governance Program Strategic, GO-PM2 Failure to formalize methodology for L, M, H
and Oversight Management Operational, inventorying, analyzing, prioritizing
Financial, and selecting eligible the Blockchain
Compliance, use cases may lead to failure of the
Legal, or program.
Reputational
Governance Program Strategic, GO-PM3 Failure to define and effectively L, M, H
and Oversight Management Operational, monitor project progress may lead to
Financial, failure of the program.
Compliance,
Legal, or
Reputational
Governance Program Strategic, GO-PM4 Failure to assess the level of change L, M, H
and Oversight Management Operational, readiness for the organization when
Financial, implementing Blockchain may lead to
Compliance, failure of program.
Legal, or
Reputational
Governance Program Strategic, GO-PM5 Failure to define the go-live criteria L, M, H
and Oversight Management Operational, within the program objectives may
Financial, lead to failure of the program.
Compliance,
Legal, or
Reputational
Governance Program Strategic, GO-PM6 Failure to identify proper resources to L, M, H
and Oversight Management Operational, fulfill roles with the Blockchain
Financial, program and lack of learning and
Compliance, development to ensure that employees
Legal, or skills are in line with the needs of the
Reputational Blockchain program leads to
excessive turnover and inadequate
resources.
Governance Program Strategic, GO-PM7 Failure to consider changes in the L, M, H
and Oversight Management Operational, business process due to Blockchain
Financial, technology could lead to loss of
Compliance, institutional knowledge.
Legal, or
Reputational
Governance Program Strategic, GO-PM8 Lack of acceptance from users and L, M, H
and Oversight Management Operational, employees of the Blockchain program
Financial, could lead to failure of the program.
Compliance,
Legal, or
Reputational
Governance Program Strategic, GO-PM9 Lack of acceptance from users and L, M, H
and Oversight Management Operational, employees of the Blockchain program
Financial, could lead to failure of the program.
Compliance,
Legal, or
Reputational
Governance Program Strategic, GO-PM10 Inadequate processes to setup L, M, H
and Oversight Management Operational, Blockchain vendor software could
Financial, lead to increased risks to security
Compliance, requirements.
Legal, or
Reputational
Governance Program Strategic, GO-PM11 Inadequate assessment of hardware, L, M, H
and Oversight Management Operational, applications, software and software
Financial, components may leave information
Compliance, systems vulnerable and unable to
Legal, or fulfill business objectives.
Reputational
Governance Program Strategic, GO-PM12 Lack of a standard process to L, M, H
and Oversight Management Operational, document functional specifications for
Financial, each business process can lead to
Compliance, incomplete or inaccurate
Legal, or documentation.
Reputational
Governance Program Strategic, GO-PM13 Failure to define and develop a clear L, M, H
and Oversight Management Operational, benefits strategy could lead to failure
Financial, of the Blockchain program.
Compliance,
Legal, or
Reputational
Governance Project Strategic, GO-PM14 Failure to assign appropriate resources L, M, H
and Oversight Management Operational, to aid in the design of application
Financial, security and controls may result in
Compliance, increased risks to the business and
Legal, or insufficient controls around the
Reputational business processes.
Governance Project Strategic, GO-PM15 Employees who are not appropriately L, M, H
and Oversight Management Operational, trained may result in an increased risk
Financial, of bypassed or forgotten
Compliance, considerations essential to the
Legal, or Blockchain Program.
Reputational
Governance Project Strategic, GO-PM16 Failure to allocate appropriate L, M, H
and Oversight Management Operational, representation and resources for the
Financial, duration of the program, may lead to
Compliance, the misuse of organizational funds and
Legal, or unintended risks to business
Reputational objectives.
Governance Project Strategic, GO-PM17 Lack of monitoring activities in place L, M, H
and Oversight Management Operational, could lead to inaccurate and
Financial, incomplete transactions processed
Compliance, within the Blockchain application.
Legal, or
Reputational
Governance Leadership Strategic, GO-LC1 Poor stakeholders and leadership L, M, H
and Oversight Commitment Operational, commitment can lead to a lack of
Financial, unity on program goals, objectives
Compliance, and performance.
Legal, or
Reputational
Governance MIS and Metrics Strategic, GO-MM1 Failure to allocate appropriate L, M, H
and Oversight Operational, resources, while considering business
Financial, requirements, may lead to the misuse
Compliance, of organizational funds and
Legal, or unintended risks to business
Reputational objectives.
Governance MIS and Metrics Strategic, GO-MM2 Inadequate controls to monitor the L, M, H
and Oversight Operational, capacity, availability, and
Financial, functionality of the application may
Compliance, lead to interruption and/or failure to
Legal, or key applications.
Reputational
Governance Operational and Strategic, GO-OC1 Failure to allocate appropriate L, M, H
and Oversight Capital Operational, resources, while considering business
Expenditure Financial, requirements, may lead to the misuse
Oversight Compliance, of organizational funds and
Legal, or unintended risks to business
Reputational objectives.
Governance Operational and Strategic, GO-OC2 Failure to allocate appropriate L, M, H
and Oversight Capital Operational, resources, while considering business
Expenditure Financial, requirements, may lead to the misuse
Oversight Compliance, of organizational funds and
Legal, or unintended risks to business
Reputational objectives.
Governance Operational and Strategic, GO-OC3 Failure to allocate appropriate L, M, H
and Oversight Capital Operational, resources, while considering business
Expenditure Financial, requirements, may lead to the misuse
Oversight Compliance, of organizational funds and
Legal, or unintended risks to business
Reputational objectives.
Governance Operational and Strategic, GO-OC4 Inadequate controls to govern and L, M, H
and Oversight Capital Operational, address security risks in a project may
Expenditure Financial, lead to loss of sensitive data.
Oversight Compliance,
Legal, or
Reputational
Governance Smart Contracts Strategic, GO-SC1 Blockchain software use cases are not L, M, H
and Oversight Operational, consistent with participants' business
Financial, or industry-specific requirements;
Compliance, smart contracts cannot be effectively
Legal, or leveraged for normal operations
Reputational
Governance Smart Contracts Strategic, GO-SC2 Blockchain implementation lacks a L, M, H
and Oversight Operational, coherent governance model for
Financial, development, execution, and oversight
Compliance,
Legal, or
Reputational
Governance Smart Contracts Strategic, GO-SC3 Lack of IP safeguards compromise the L, M, H
and Oversight Operational, organization's DLT innovations
Financial,
Compliance,
Legal, or
Reputational
After categorizing the risks as described above, the framework can then present the user with series of control/test objectives (with corresponding descriptions) which the user can review and determine whether such controls/test objectives should be considered in-scope to the audit or out of scope to the audit. An exemplary control/test objective table is provided below for the governance and oversight risk category.
TABLE 3
In-scope/Out-
of-Scope
Risk (TBD - As per
Category Domain Control/Test Objective Control Description engagement)
Governance Business At the senior management level, The Blockchain Program Charter is In-scope
and Oversight Objectives business justification and created and includes specific details of
objectives for the Blockchain goals and business objectives of the
Program is documented and overall Blockchain Program. The
aligns with business strategy. Blockchain steering committee reviews
The Blockchain Program is and approves The Blockchain Program
considered in the overarching Charter to ensure it is in alignment with
governance framework with the firm's organizational and
alignment to risk, compliance governance strategies.
and IT/data frameworks.
Governance Business The Blockchain Program is A Blockchain steering committee, In-scope
and Oversight Objectives appropriately prioritized against which includes executive leadership
other initiatives within the and senior members of the business,
organization. risk, compliance and the Blockchain
program management, meets on a
quarterly basis to conduct business
performance reviews of how the
Blockchain Program aligns with
business strategy.
Governance Business The Blockchain program project The scope of the Blockchain program is In-scope
and Oversight Objectives plan has been defined outlined in the Blockchain project
addressing each phase of the plan/roadmap. The project plan is
Blockchain program project and reviewed and approved by the steering
is consistent with the scope and committee to ensure the plan is in
objectives defined within the alignment with the Blockchain Program
program charter. The scope of Charter.
the Blockchain Program has
been approved and
communicated by all
participants.
Governance Program Senior Management is actively The Blockchain Program Charter is In-scope
and Oversight Sponsorship involved in creating created and includes specific details of
organizational awareness, the communication strategy to the
championing the Blockchain broader organization. The Blockchain
program. steering committee reviewed and
approved The Blockchain Program
Charter.
Governance Program Key Performance Indicators Key Performance Indicators (KPIs) are In-scope
and Oversight Management (KPIs), specific to the established to monitor the Blockchain
Blockchain use case, to monitor program performance.
program performance have been
developed.
Governance Program Formalized methodology for The Blockchain program policies and In-scope
and Oversight Management inventorying, analyzing, procedures, which includes
prioritizing and selecting methodology for inventorying,
eligible the Blockchain use analyzing, prioritizing and selecting
cases exists. This method is eligible the Blockchain use cases, are
formally documented to ensure reviewed and approved on a periodic
consistently across business basis.
units that may potentially utilize
the technology.
Governance Program The Blockchain program project The Blockchain Program steering In-scope
and Oversight Management plan has been defined committee reviewed and approved The
addressing every phase of the Blockchain program project plan. The
Blockchain program project and Blockchain program management
is consistent with the scope and monitors individual project work plans
objectives defined within the to measure progress against The
program charter. Individual Blockchain project plan.
project work plans are well
defined and effectively
monitored for project progress;
an integrated master plan that
provides a comprehensive view
of work effort and dependencies
across all project teams has
been defined.
Governance Program Affected stakeholders are The processes selected for Blockchain In-scope
and Oversight Management actively involved in the implementation are evaluated on a
planning process and the quarterly basis by the Blockchain
Blockchain Program team has program management team to ensure
formally assessed the level of the Blockchain technology is being
change readiness for the optimized and decisions adhere to the
organization and its business Blockchain selection criteria outlined in
units, stakeholders, and the Blockchain program policies and
customers. procedures. The results of this
evaluation are reported to the
Blockchain steering committee.
Governance Program Formal go-live criteria for each Formal policies and procedures have In-scope
and Oversight Management application/use case is been established and documented to
adequately linked back to the outline the methodology for the
program scope and objectives. Blockchain configuration and
maintenance, including decision
making criteria to go live being
formally documented. Policies and
procedures are reviewed and approved
on a periodic basis.
Governance Program Management has updated The Blockchain program policies and In-scope
and Oversight Management staffing and hiring practices to procedures, which includes details of
ensure the right people within the formal the Blockchain organization
the organization are identified structure, staffing and training
and assigned as the Blockchain requirements are reviewed and
program resources. Learning approved on a periodic basis.
and development personnel
have been engagement to ensure
training program has been
instituted to train the
Blockchain Program staff.
Governance Program There has been adequate Periodically, management performs a In-scope
and Oversight Management considerations for loss of risk assessment of the Blockchain
institutional knowledge as the technology and evaluates the risk
Blockchain technology alters/ associated with loss of institutional
eliminates steps in business knowledge.
processes.
Governance Program There is adequate Management has considered the impact In-scope
and Oversight Management considerations for the that the Blockchain program will have
organizations resistance to on resources and has designed a formal
change and appropriate people people and change process to mitigate
and change management possible disruptions and resistance
processes are put into place to across the organization.
clearly articulate the future state
and address possible disruption
discomfort with a new
technologically sophisticated
process that will result in large
decreases in manpower
requirements.
Governance Program A formal process to address The Blockchain Program Charter In-scope
and Oversight Management organizational changes, outlines a formal process to address
including the ability to perform organizational changes. The
tasks in case of the Blockchain organizational change process is
failure. analyzed and evaluated on a monthly
basis by the Blockchain program
management team. The results of this
evaluation are reported to The
Blockchain steering committee.
Governance Program The setup of the Blockchain The Blockchain vendor software for In-scope
and Oversight Management vendor software includes initial integration into the firm's
consideration of new security environment follows a well-defined
requirements to maintain integration plan and is monitored by the
confidentiality, integrity, and Blockchain program management.
availability have been
considered.
Governance Program Hardware (including Impact of software integration on the In-scope
and Oversight Management configurations, locations, firm's existing hardware configurations,
capacity/capacity utilization, software and applications is
and age and data requirements), documented and evaluated. The results
applications, software and of this evaluation are reported to the
software components impacted Blockchain Program steering
by the Blockchain integration committee.
have been identified, evaluated
and reported on.
Governance Program The process to create functional The Blockchain program policies and In-scope
and Oversight Management specifications for each new procedures, which includes the process
Blockchain business process to create functional specifications for
follows a standard process each new the Blockchain business
documented in the Blockchain process, are reviewed and approved on
Program policies and a periodic or as needed basis.
procedures.
Governance Program A benefits realization strategy The Blockchain Program Charter is In-scope
and Oversight Management has been developed and created and includes the Blockchain
approved. Benefits Management process. The
Blockchain Program steering
committee reviews and approves the
Blockchain Program Charter to ensure
it is in alignment with the firm's
organizational and governance
strategies.
Governance Project Appropriate members of the The Blockchain program management In-scope
and Oversight Management business, the Blockchain team includes members from risk and
program team, risk, and compliance responsible for designing
compliance are actively and implementing key controls being
involved in design of executed by the Blockchain
application security and technology. The functional
controls. specifications for each new the
Blockchain business process are
reviewed by the Blockchain Program
risk & compliance team member to
assure the appropriateness of the design
and operating effectiveness of controls
the Blockchain is executing.
Governance Project Individuals are properly trained The Blockchain Program configuration In-scope
and Oversight Management to configure the Blockchain analysts are required to complete
technology. training prior to being involved with
functional or technical Blockchain
design. On an ongoing basis,
individuals involved in the Blockchain
program receive updated education to
keep current with emerging technology
issues.
Governance Project There is adequate commitment The Blockchain policies and In-scope
and Oversight Management to provide appropriate procedures are defined and include a
representation and resources for description of key Blockchain program
the duration of the Blockchain management positions, responsibilities
program. and overall organization structure for
governance.
Governance Project Post implementation, there are Post implementation reviews are In-scope
and Oversight Management monitoring activities in place to performed by the required business
monitor the completeness and and/or technology management or
accuracy of processing for the designee to test the completeness and
Blockchain transactions. accuracy of processing for the
Blockchain transactions.
Governance Leadership The Blockchain program Leadership discusses and engages with In-scope
and Oversight Commitment stakeholders have been the business to determine Blockchain
adequately engaged and goals and objectives. The Blockchain
understand the Blockchain Program Charter is created and
program goals and objectives. includes specific details of goals and
business objectives of the overall the
Blockchain Program. The Blockchain
steering committee reviews and
approves The Blockchain Program
Charter to ensure it is in alignment with
the firm's organizational and
governance strategies.
Governance MIS and There is a formal process for The Blockchain project plan/roadmap In-scope
and Oversight Metrics monitoring the Blockchain details the financial needs of each
program project performance individual project work stream. The
and details of performance is Blockchain program management has a
communicated to appropriate formal process to monitor project costs
stakeholders. as it relates to project progress,
milestones, and deliverables, as well as
specifics to measure KPI, ROI per
process and overall ROI. Monthly, the
project costs are reported back to the
Blockchain steering committee.
Governance MIS and There is sufficient oversight Daily, the Blockchain Operational In-scope
and Oversight Metrics over the application by to management reviews capacity,
ensure the Blockchain is logged, availability and performance metrics of
functioning, and workloads, the Blockchain in production.
availability and capacity are Deviations from standard metrics are
being efficiently and effectively noted, researched and resolved.
balanced. Monthly these metrics are report to the
Blockchain Program steering
committee.
Governance Operational and Financial needs of the program The Blockchain Program Charter is In-scope
and Oversight Capital have been reviewed and created and includes the financial needs
Expenditure approved by senior management of the Blockchain program. The
Oversight and assessment of those needs Blockchain steering committee reviews
are reassessed on an ongoing and approves the Blockchain Program
basis. Charter. Additionally, the Blockchain
project plan/roadmap details the
financial needs of each individual
project work stream.
Governance Operational and The organization allocates The organization establishes a plan for In-scope
and Oversight Capital appropriate resources to the allocation of appropriate resources
Expenditure information security and risk to projects and programs based on
Oversight management. assessing organizational, operational,
and strategic considerations.
Governance Operational and The organization allocates Resources (human, technology, In-scope
and Oversight Capital appropriate resources to finance) required to achieve security
Expenditure information security and risk objectives are allocated for the
Oversight management. establishment, implementation,
maintenance and continual
improvement of the information
security management system.
Governance Operational and Implement security controls in Information security is addressed in In-scope
and Oversight Capital projects. project management, regardless of the
Expenditure type of the project.
Oversight
Finally once the user has identified the risks (including their particular levels), and has determine which test objectives are in-scope and out-of-scope to the validation, the risk framework can then provide the user with the applicable tests that will be applied to the user's blockchain validation system. The table below can be created based on the user's inputs to the reference framework described above. The table below can indicate the test procedures to be performed that determine the design or operating effectiveness of a control specified in table 3. The table below can also specify the test type which can be inquiry, inspection and observation, as well as attribute or substantive type of testing using a manual or automated approach. Finally, the table below can also present the user with a request list that can show the user requested items to be gathered to provide supporting information such as documentation or evidence including data parameters to execute test procedures in order to obtain the specified level of assurance and confidence surrounding the process and technology.
TABLE 4
Test Type
(TBD - As
Risk per
Category Domain Test Procedure (#) engagement) Request List (#)
Governance Business 1. Verify the Blockchain Program Inquiry, 1. Blockchain Program Charter
and Objectives Charter has been created and review Inspection, 2. Meeting minutes from the Steering
Oversight the overall goals and business and/or committee meeting where the Blockchain
objectives. observation Program charter was reviewed.
2. Inspect the Blockchain Program
Charter to ensure the Steering
committee has reviewed and
approved it.
Governance Business 1. Inquire with Blockchain steering Inquiry, 1. Meeting minutes from the Steering
and Objectives committee members to determine Inspection, committee where business performance
Oversight criteria for business reviews to and/or reviews of how the Blockchain Program
assess the Blockchain program's observation aligns with business strategy are discussed
alignment with business strategy and reviewed.
2. Inspect Quarterly meeting
minutes to confirm that business
performance reviews were
conducted by the established
criteria.
Governance Business 1. Inspect the Blockchain project Inquiry, 1. Blockchain project plan/roadmap
and Objectives plan/roadmap to confirm that scope Inspection, 2. Blockchain Program Charter
Oversight of program is outlined. and/or 3. Meeting minutes from the Steering
2. Inquire with Steering committee observation committee where project plan/roadmap was
to ensure that plan was reviewed reviewed and approved.
and approved, as evidence that plan
is in line with Blockchain Program
Charter.
Governance Program 1. Inquire and inspect the Inquiry, 1. Blockchain Program Charter
and Sponsorship Blockchain Program Charter to Inspection, 2. Evidence that the Blockchain Program
Oversight confirm details regarding the and/or Charter was reviewed and approved.
communication strategy to the observation
broader organization.
2. Inspect that the Blockchain
Program Charter has been reviewed
and approved.
Governance Program 1. Inquire with Blockchain Inquiry, 1. Blockchain Program KPIs
and Management Operational Management to ensure Inspection,
Oversight Key Performance Indicators (KPIs) and/or
have been established and observation
monitored.
2. Inspect evidence to determine
KPIs are monitored periodically.
Governance Program 1. Inquire with management on Inquiry, 1. Blockchain program policies and
and Management methodology for inventorying, Inspection, procedures.
Oversight analyzing, prioritizing and selecting and/or 2. Evidence of review and approval on a
eligible the Blockchain use cases. observation periodic basis of the Blockchain program
2. Obtain and inspect Blockchain policies and procedures.
program policies and procedures
and confirm that methodology for
inventorying, analyzing, prioritizing
and selecting eligible the
Blockchain use cases is included.
3. Inquire with management and
inspect that program policies and
procedures are reviewed and
approved on a periodic basis.
Governance Program 1. Inquire with Steering committee Inquiry, 1. Blockchain Program Charter
and Management to ensure that plan was reviewed Inspection, 2. Meeting minutes from the Steering
Oversight and approved, as evidence that plan and/or committee meeting where the Blockchain
is in line with Blockchain Program observation Program charter was reviewed.
Charter. 3. Blockchain Project Plan
2. Inquire with the Blockchain
program management to determine
the criteria of monitoring the
individual project work plans to
ensure the progress is measured
against the Blockchain project plan.
Governance Program 1. Inquire with the Blockchain Inquiry, 1. Blockchain Program Charter (policies
and Management program management team to Inspection, and procedures)
Oversight determine that the Blockchain and/or 2. Evidence of Blockchain selection criteria
implementation processes are observation within the Blockchain Program Charter
evaluated on a quarterly basis and 3. Blockchain implementation processes
to ensure they adhere to the 4. Blockchain implementation evaluation
Blockchain selection criteria report
outlined in the Blockchain Program
Charter.
2. Inquire with Steering Committee
to ensure they receive the
evaluation of the Blockchain
implementation processes.
Governance Program 1. Inspect the Blockchain Inquiry, 1. Blockchain Configuration and
and Management Configuration and Maintenance Inspection, Maintenance Methodology
Oversight methodology to ensure formal and/or 2. Evidence of decision making criteria to
policies and procedures have been observation go live
documented and include decision 3. Evidence of review and approval of the
making criteria to go live. Blockchain Configuration and Maintenance
2. Inspect the Blockchain Methodology on a periodic basis
Configuration and Maintenance
methodology to ensure the policies
and procedures have been reviewed
and approved on a periodic basis.
Governance Program 1. Obtain and inspect the Inquiry, 1. Blockchain program policies and
and Management Blockchain program policies and Inspection, procedures
Oversight procedures, and review for details and/or 2. Evidence of review and approval on a
of the formal the Blockchain observation periodic basis of the Blockchain program
organization structure, staffing and policies and procedures.
training requirements.
2. Inquire with management and
inspect the policies and procedures
to confirm that they have been
reviewed and approved on a
periodic basis.
Governance Program 1. Inquire with management about Inquiry, 1. Risk assessment performed by
and Management the process to evaluate the risks Inspection, management
Oversight regarding loss of institutional and/or
knowledge. observation
2. Obtain and inspect the risk
assessment performed by
management, review that the risk
has been evaluated.
Governance Program 1. Inquire with management about Inquiry, 1. Formal people and change process
and Management the people and change process. Inspection, document
Oversight 2. Obtain and inspect the formal and/or
people and change process. observation
Governance Program 1. Inquire with management Inquiry, 1. Blockchain Program Charter
and Management regarding the formal process to Inspection, 2. Evidence that evaluation of the change
Oversight address organizational changes. and/or process is evaluated and presented to the
2. Obtain and inspect the observation Blockchain steering committee.
Blockchain Program Charter to
confirm that is outlines a formal
process to address organizational
changes.
3. Inquire with the Blockchain
program management team to
confirm that the change process is
analyzed and evaluated on a
monthly basis.
4. Inquire with Blockchain steering
committee to confirm that results of
the evaluation are reported.
Governance Program 1. Inquire with management on the Inquiry, 1. Integration procedures for vendors
and Management integration procedure in place for Inspection,
Oversight new vendor software. and/or
2. Obtain and inspect the integration observation
plan and review to confirm that the
Blockchain program management
team
Governance Program 1. Inquire with management on the Inquiry, 1. Documentation and evaluation of
and Management documentation and evaluation of Inspection, hardware, applications, software and
Oversight hardware, applications, software and/or software components related to the
and software components related to observation Blockchain
the Blockchain. 2. Evidence of evaluation reported to the
2. Obtain and inspect the formal Blockchain Program steering committee.
documentation and evaluation of
hardware, applications, software
and software components related to
the Blockchain.
3. Inspect evidence that the results
of the evaluation are presented and
reported to the Blockchain Program
steering committee.
Governance Program 1. Inquire with management on Inquiry, 1. Policies and procedures to create the
and Management policies and procedures to create the Inspection, functional specifications.
Oversight functional specifications. and/or 2. Evidence that the process was reviewed
2. Obtain and inspect the policies observation and approved.
and procedures to create the
functional specifications.
3. Inspect evidence that the process
is reviewed and approved on a
periodic or as needed basis.
Governance Program 1. Inquire and inspect the Inquiry, 1. Blockchain Program Charter
and Management Blockchain Program Charter to Inspection, 2. Evidence that the Blockchain Program
Oversight confirm details regarding the and/or Charter was reviewed and approved.
Benefits Management process. observation
2. Inspect that the Blockchain
Program Charter has been reviewed
and approved by the Blockchain
program steering committee.
Governance Project 1. Inquire with management on the Inquiry, 1. Functional specifications
and Management process and appropriateness of Inspection, 2. Evidence that employees involved in the
Oversight resources used to design functional and/or design are appropriate and possess the
specifications and confirm that they observation proper qualifications
are reviewed by the Blockchain
program risk and compliance team.
2. Inspect functional specifications
to assure appropriateness of the
design and operating effectiveness
of controls.
Governance Project 1. Inquire with management about Inquiry, 1. Training plan
and Management the training requirements for Inspection, 2. Training materials
Oversight analysts involved with the and/or
functional and/or technical design. observation
2. Inspect training plan or training
materials provided to analysts,
including any on-going training.
Governance Project 1. Inquire with management on Inquiry, 1. Policies and procedures that provide a
and Management policies and procedures that provide Inspection, description of key Blockchain program
Oversight a description of key Blockchain and/or management positions, responsibilities and
program management positions, observation overall organization structure for
responsibilities and overall governance.
organization structure for
governance.
2. Obtain and inspect the policies
and procedures that provide a
description of key Blockchain
program management positions,
responsibilities and overall
organization structure for
governance.
Governance Project 1. Inquire with management on the Inquiry, 1. Reviews performed to test completeness
and Management reviews performed to test Inspection, and accuracy of processing for the
Oversight completeness and accuracy of and/or Blockchain transactions.
processing for the Blockchain observation
transactions.
2. Obtain and inspect the reviewed
performed to test completeness and
accuracy of processing for the
Blockchain transactions.
Governance Leadership 1. Verify the Blockchain Program Inquiry, 1. Blockchain Program Charter
and Commitment Charter has been created and review Inspection, 2. Meeting minutes from the Steering
Oversight the overall goals and business and/or committee meeting where the Blockchain
objectives. Review the members of observation Program charter was reviewed.
the organization who have
contributed to the Blockchain
Program Charter to confirm
appropriate leadership engagement.
2. Inspect the Blockchain Program
Charter to ensure the Steering
committee has reviewed and
approved it.
Governance MIS and 1. Inspect the Blockchain project Inquiry, 1. Blockchain Project Plan/roadmap
and Metrics plan/roadmap to confirm the Inspection, 2. Evidence of formal process to monitor
Oversight financial needs are outlined. and/or and report project costs
2. Inquire with the Blockchain observation 3. Evidence of performance metrics
program management to determine
there is a formal process to monitor
project costs and measure
performance in place.
3. Inquire with the Blockchain
steering committee to ensure the
project costs are reported to them
on a monthly basis.
Governance MIS and 1. Obtain daily Blockchain Inquiry, 1. Daily Blockchain Capacity, Availability,
and Metrics capacity, availability, and Inspection, and Performance Metrics
Oversight performance metrics. and/or 2. Evidence of daily review of the metrics
2. Inquire with Blockchain observation by the Blockchain Operational
Operational Management to Management
determine the criteria for reviewing 3. Evidence of reporting the metrics to the
the metrics daily and inspect the Blockchain Program Steering Committee
evidence to ensure the metrics are
reviewed daily and if there are
deviations they are noted,
researched and resolved.
3. Inspect the evidence of the
metrics to ensure they are reported
monthly to the Blockchain Program
Steering Committee.
Governance Operational 1. Inquire with the Blockchain Inquiry, 1. Blockchain Program Charter
and and Capital steering committee members to Inspection, 2. Meeting minutes from the Steering
Oversight Expenditure determine criteria for financial and/or committee meeting where the Blockchain
Oversight needs are included in the observation Program charter was reviewed.
Blockchain Program Charter. 3. Blockchain Project Plan/Roadmap
2. Inspect the Blockchain Program 4. Evidence of each individual Blockchain
Charter to ensure the Steering project work stream's financial needs
committee has reviewed and
approved it.
3. Inspect the Blockchain Project
Plan/Roadmap to ensure the
financial needs of each individual
project work stream is included and
outlined.
Governance Operational 1. Obtain a copy of the Inquiry, 1. Organizations plans and/or documents
and and Capital organizations process and/or plans Inspection, for allocation of funds
Oversight Expenditure for allocating resources and verify it and/or
Oversight takes the following factors into observation
consideration:
people, skills, experience and
competence;
resources needed for each step of
the risk management process;
the organization's risk processes,
methods and tools to be used for
managing risk;
documented processes and
procedures;
information and knowledge
management systems;
training programs.
Governance Operational 1. Inquire with the control owner Inquiry, 1. Documentation for the most recent
and and Capital and confirm if the organization has Inspection, annual budget planning exercise.
Oversight Expenditure processes in place to identify and/or 2. Evidence that the organization has
Oversight additional expertise needed to observation processes in place to identify additional
improve information security expertise needed to improve information
defenses. security defenses.
2. Determine if the size and quality 3. Provide a list the organization's security
of the organization's security staff staff, including their positions and
is adequately staffed and structured expertise.
handle the impact of staff turnover.
Governance Operational 1. Inquire with management how Inquiry, 1. Project management methodology or
and and Capital security is embedded in the project Inspection, process documentation.
Oversight Expenditure management process/lifecycle. and/or 2. Population: System extract or register of
Oversight 2. Obtain project methodology or observation projects
process documentation and validate 3. For a sample of projects selected,
that it considers security risks as evidence of risk assessment activities being
part of the process. performed as part of the project
management lifecycle.
4. ISMS manual - Description of the
security requirements department managers
are to include in projects.
In some embodiments, cybersecurity risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance surrounding the cybersecurity and privacy management activities.
The sub-risk categories, control and testing objectives, test procedures and request lists for Cyber Security risk category are provided below in Tables 5-7. The tables below are formatted in the same manner as tables 2-4 described above, and thus for an explanation of each column below, the corresponding discussion above can be referenced.
TABLE 5
Risk Level (L,
Risk Risk M, H)
Risk Category Domain Classification Number Risk Description (As applicable)
Cyber Security Cloud Security Strategic, CS-CS1 Without clearly defined roles L, M, H
Operational, and responsibilities with cloud
Financial, service providers and SLA in
Compliance, place, accountability is lost
Legal, or when issues in the relationship
Reputational arise.
Cyber Security Cloud Security Strategic, CS-CS2 Without clearly defined roles L, M, H
Operational, and responsibilities with cloud
Financial, service providers and SLA in
Compliance, place, accountability is lost
Legal, or when issues in the relationship
Reputational arise.
Cyber Security Cloud Security Strategic, CS-CS3 Lack of established and L, M, H
Operational, implemented safeguards may
Financial, lead to supply chain
Compliance, information, system component,
Legal, or and information system
Reputational vulnerabilities
Cyber Security Cloud Security Strategic, CS-CS4 Lack of adherence to the L, M, H
Operational, documented production
Financial, network standards may lead to
Compliance, increased security risk.
Legal, or
Reputational
Cyber Security Cloud Security Strategic, CS-CS5 Unauthorized access of L, M, H
Operational, information stored in shared
Financial, resources can result in
Compliance, inappropriate access, changes or
Legal, or loss.
Reputational
Cyber Security Data Security Strategic, CS-DS1 Data exchanged through L, M, H
Operational, communication facilities may
Financial, be intercepted and accessed by
Compliance, unauthorized agents within or
Legal, or outside the organizations
Reputational network.
Cyber Security Data Security Strategic, CS-DS2 Procedures which do not L, M, H
Operational, facilitate appropriately
Financial, classifying, labeling and
Compliance, handling information based on
Legal, or its value, business and legal
Reputational requirements may expose
information to deliberate or
accidental misuse.
Cyber Security Data Security Strategic, CS-DS3 Lack of controls to protect L, M, H
Operational, information can lead to data
Financial, leaks or exposures that threaten
Compliance, the organization's reputation
Legal, or and could lead to litigation.
Reputational
Cyber Security Data Security Strategic, CS-DS4 Lack of alignment with the L, M, H
Operational, organization's risk strategy and
Financial, risk appetite in the protection of
Compliance, data may compromise the
Legal, or confidentiality, integrity and
Reputational availability of information in
Blockchain systems.
Cyber Security Data Security Strategic, CS-DS5 Failure to establish and L, M, H
Operational, communicate policies and
Financial, procedures for information
Compliance, security relevant to Blockchain
Legal, or use case may result in gaps in
Reputational security capabilities needed to
reduce the organization's cyber
risk exposure in accordance
with its risk appetite.
Cyber Security Data Privacy Strategic, CS-DP1 Lack of controls to protect L, M, H
Operational, information can lead to data
Financial, privacy or exposures that
Compliance, threaten the organization's
Legal, or reputation and could lead to
Reputational litigation.
Cyber Security Data Privacy Strategic, CS-DP2 Failure to establish and L, M, H
Operational, communicate policies and
Financial, procedures for privacy may
Compliance, result in gaps in privacy
Legal, or capabilities needed to reduce
Reputational the organization's privacy risk
exposure in accordance with its
risk appetite.
Cyber Security Data Privacy Strategic, CS-DP3 Lack of a privacy policy may L, M, H
Operational, increase the risk that
Financial, information is disclosed or used
Compliance, without the owner's consent,
Legal, or resulting in litigation and
Reputational reputational damage.
Cyber Security Penetration Strategic, CS-PT1 Inadequately defined processes L, M, H
Testing Operational, for technical vulnerability
Financial, management and ineffective
Compliance, testing or detection of
Legal, or vulnerabilities may result in
Reputational inappropriate or unauthorized
access to information.
Cyber Security Network Strategic, CS-NS1 Failure to protect network L, M, H
Security Operational, perimeter may result in
Financial, unauthorized access.
Compliance,
Legal, or
Reputational
Cyber Security Patch and Strategic, CS-PVM1 Lack of proper information L, M, H
Vulnerability Operational, system management flaw
Management Financial, management may result in
Compliance, security vulnerabilities
Legal, or
Reputational
Cyber Security Patch and Strategic, CS-PVM2 Inadequately defined processes L, M, H
Vulnerability Operational, for technical vulnerability
Management Financial, management and ineffective
Compliance, testing or detection of
Legal, or vulnerabilities may result in
Reputational inappropriate or unauthorized
access to information.
Cyber Security Patch and Strategic, CS-PVM3 Inadequate processes for system L, M, H
Vulnerability Operational, updates and patch management
Management Financial, may result in compromise of
Compliance, system security due to the latest
Legal, or updates and patches not being
Reputational installed in a timely manner.
Cyber Security Threat Strategic, CS-TD1 The lack of logging L, M, H
Detection Operational, mechanisms results in the
Financial, inability to track unauthorized
Compliance, activity.
Legal, or
Reputational
Cyber Security Threat Strategic, CS-TD2 Inadequate processes for L, M, H
Detection Operational, logging and monitoring
Financial, Blockchain system activities
Compliance, may result in unauthorized
Legal, or information processing
Reputational activities going undetected.
Cyber Security Threat Strategic, CS-TD3 Lack of monitoring mechanisms L, M, H
Detection Operational, may result in breaches and
Financial, sensitive data exposure.
Compliance,
Legal, or
Reputational
Cyber Security Threat Response Strategic, CS-TR1 Absence of a formalized L, M, H
Operational, Security Incident Response
Financial, Program may result in
Compliance, uncoordinated processes in
Legal, or response to a security incident.
Reputational
Cyber Security Threat Response Strategic, CS-TR2 Absence of a formalized L, M, H
Operational, Security Incident Response
Financial, Program may result in
Compliance, uncoordinated processes in
Legal, or response to a security incident.
Reputational
Cyber Security Threat Response Strategic, CS-TR3 Incidents that are not controlled L, M, H
Operational, may lead to pervasive problems
Financial, throughout the organization.
Compliance,
Legal, or
Reputational
Cyber Security Programming Strategic, CS-PS1 In adequate security measures L, M, H
Security Operational, within the development
Financial, lifecycle of information systems
Compliance, may lead to unauthorized
Legal, or changes.
Reputational
Cyber Security Programming Strategic, CS-PS2 Systems with vulnerabilities L, M, H
Security Operational, may be developed and
Financial, implemented in the production
Compliance, environment.
Legal, or
Reputational
Cyber Security Programming Strategic, CS-PS3 Systems with vulnerabilities L, M, H
Security Operational, may be developed and
Financial, implemented in the production
Compliance, environment.
Legal, or
Reputational
Cyber Security Programming Strategic, CS-PS4 Systems with vulnerabilities L, M, H
Security Operational, may be developed and
Financial, implemented in the production
Compliance, environment.
Legal, or
Reputational
Cyber Security Programming Strategic, CS-PS5 Untested changes may lead to L, M, H
Security Operational, interruption and/or unintended
Financial, consequences to the
Compliance, organization.
Legal, or
Reputational
Cyber Security Programming Strategic, CS-PS6 Insecure coding practices, L, M, H
Security Operational, especially within the application
Financial, layer, can introduce security
Compliance, vulnerabilities and increase the
Legal, or risk to internal and external
Reputational threats.
Cyber Security Programming Strategic, CS-PS7 Use of production or live data L, M, H
Security Operational, for development and/or testing
Financial, purposes can cause unintended
Compliance, corruption or manipulation of
Legal, or the data.
Reputational
Cyber Security Smart Contracts Strategic, CS-SM1 Input validation mechanisms for L, M, H
Operational, fields and records are not in
Financial, place, creating the risk of failed
Compliance, conversion of data from input to
Legal, or outputs
Reputational
TABLE 6
In-scope/Out-of-
Scope
Control/Test (TBD - As per
Risk Category Domain Objective Control Description engagement)
Cyber Security Cloud Security Contracts with the Cloud Contracts between the Cloud In-scope
Service provider specify Service Provider and the
required information organization specifies appropriate
security and processing security and processing measures,
measures. and establish data are not
processed for any non-specified
purpose without approval.
Cyber Security Cloud Security Cloud service providers A contract is signed between both In-scope
and understand roles & parties detailing the roles and
responsibilities, responsibilities of each party,
including requirements to including information security
address information requirements, confidentiality/non-
security risks for disclosure agreements,
confidentiality, and the obligations, and the obligations of
secure transfer of employees and subcontractors.
information.
Cyber Security Cloud Security The organization Organizational safeguards such as In-scope
employs measures to the identification, management
protect against supply and reduction of vulnerabilities
chain threats from cloud are employed to protect the
service providers that supply chain against information
impact the Blockchain system, system components, and
information system, information system services
system component, or threats.
information system
service.
Cyber Security Cloud Security Cloud services are Secure standardized network In-scope
secured using standard protocols are in place to manage
network protocols, and the cloud service and
interoperability and documentation detailing relevant
portability standards are interoperability and portability
available to customers. standards are made available to
customers.
Cyber Security Cloud Security Blockchain systems are The Blockchain system are In-scope
configured to prevent configured to prevents
unauthorized access and unauthorized and unintended
transfer of information information transfer via shared
through shared system system resources. Re-use of
resources. shared resources is monitored and
controlled to prevent
unauthorized access.
Cyber Security Data Security Data exchange is Formal information exchange In-scope
controlled, encrypted, requirements have been
and protected while the established and Blockchain
information is at rest or systems are configured to protect
transferred between the exchange of information
systems. through the use of all types of
communication facilities and
interfaces.
Cyber Security Data Security Resources (e.g., Information assets (e.g., In-scope
hardware, devices, data, hardware, devices, data, and
and software) are software) are classified based on
classified based on their their criticality and sensitivity.
criticality and business Information is handled and
value. protected in accordance with its
classification, criticality, and
business value to the
organization.
Cyber Security Data Security Protections against data The organization employs data In-scope
leaks are implemented. mining prevention and detection
techniques for data storage
objects supporting Blockchain
use case to adequately detect and
protect against data mining.
Cyber Security Data Security Data in Blockchain Information and records (data) in In-scope
systems is protected Blockchain systems are managed
according to the risk consistent with the organization's
strategy and risk appetite risk strategy to protect the
of the organization. confidentiality, integrity, and
availability of information.
Cyber Security Data Security Policies and procedures Information security policies and In-scope
for direction and support applicable procedures have been
of organizational systems formally documented in
and applications exist in accordance with organization's
accordance with business risk objectives, applicable legal
requirements and and regulatory requirements, have
relevant laws and been approved by Management,
regulations. and have been communicated to
all employees and relevant
external parties. The policies and
procedures are reviewed on a
periodic basis based on changes
to the internal and external
environment and to support
management's objective of
continuous improvement of the
organization's information
security capabilities.
Cyber Security Data Privacy Protections against data Unauthorized leaks of data, In-scope
privacy are implemented specifically PII and PHI, are
in Blockchain systems to prevented or detected. The
prevent unauthorized processor prevents or monitors
view or exposures of for unauthorized leakage of data,
confidential information. or enables the capability for its
customers to prevent or monitor
for the unauthorized leakage of
data. DLP tools monitor
outbound communications traffic
at the external boundary of the
information system (i.e., system
perimeter) and at interior points
within the system (e.g.,
subsystems, subnetworks) to
detect covert exfiltration of
information.
Cyber Security Data Privacy Policies and procedures Information security policies and In-scope
for direction and support procedures around information
of information privacy privacy are documented and
exist in accordance with available to personnel on
business requirements accessible resources. The policies
and relevant laws and and procedures are
regulations. reviewed/updated periodically.
Cyber Security Data Privacy The organization The privacy policy discloses the In-scope
discloses how it uses PII ways that the organization
in accordance with the gathers, uses, discloses, and
public notice manages PII. It fulfills the legal
requirement. requirement to protect PII and
declares the company's policy on
how it collects, stores, and
releases the PII it collects, and
inform whether PII is kept
confidential, shared with partners,
or sold to other firms or
enterprises.
Cyber Security Penetration Asset vulnerabilities are Penetration tests of the In-scope
Testing monitored, identified and production environment are
documented. performed on a periodic basis or
after any significant infrastructure
or application upgrade or
modification. Remediation plans
are developed to address the
risks. The penetration testing
methodology aligns with industry
standard practices and covers
application-layer and network-
layer. Testing is performed both
inside and outside the network.
Test results are retained for a
specific period of time.
Cyber Security Network Network perimeter is Firewalls and routers are In-scope
Security protected using managed configured to:
boundary protection Restrict inbound and outbound
devices. traffic to that which is necessary
(e.g., deny by default, permit by
exception)
Restrict connections between
untrusted networks and any
system components
Fail securely in case of an
operational failure
Permit only authorized traffic
between wireless environment
and cardholder data environment
Firewall and router configuration
standards are in place to define
network connection requirements.
The firewall and router
configuration standards include
the following:
Business justification and
approval for use of all services,
protocols, and ports allowed,
including security features
implemented for those protocols
considered to be insecure (e.g.,
FTP, Telnet, POP3, IMAP, and
SNMP v1 and v2)
Roles and responsibilities for
management of network
components.
Exceptions to the standards are
documented and reviewed on a
periodic basis.
There is a formal process for
testing and approval of all
network connections and changes
to firewall and router
configurations.
For any public-facing Web
applications, an automated
technical solution that detects and
prevents web-based attacks (for
example, a web-application
firewall) has been installed, to
continually check all traffic.
A DMZ is implemented to limit
inbound traffic to only system
components that provide
authorized publicly accessible
services, protocols, and ports.
Inbound Internet traffic is limited
to IP addresses within the DMZ.
A firewall is required at each
internet connection and between
any DMZ and the intranet.
The information system routes
internal communications traffic to
external networks through
authenticated proxy servers (e.g.,
web content filters with a defined
list of authorized and
unauthorized websites)
Anti-spoofing measures are
implemented to detect and block
forged source IP addresses from
entering the network.
Cyber Security Patch and Identify, report and A vulnerability management In-scope
Vulnerability correct information program exists to identify and
Management systems flaws in a timely manage vulnerabilities in a
manner. centralized, streamlined and
organized manner. The technical
vulnerability management
program is evaluated on a
quarterly basis.
Cyber Security Patch and System vulnerability Vulnerability scans and rescans In-scope
Vulnerability scanning is performed to are performed by qualified
Management identify threats. personnel on both external and
internal facing production
systems using internal scanning
resources on a periodic basis and
when new vulnerabilities
affecting the systems are known.
Commercial and proprietary
vulnerability scanning tools are
configured to identify
vulnerabilities. Identified critical
vulnerabilities are remediated
timely. Remediation status is
monitored and non-compliance is
escalated.
Cyber Security Patch and System vulnerabilities A patch management program In-scope
Vulnerability are mitigated through exists to incorporate, test, and
Management patches. implement firmware updates and
patches in a timely fashion
Cyber Security Threat Detection Logging mechanisms and Logging mechanisms are In-scope
the ability to track configured to enable the
activity is established, monitoring, analysis,
tracked, and monitored. investigation, and reporting of
unlawful, unauthorized, or
inappropriate information system
activity: The following events are
tracked:
General user access and
activities
Root access and activities
Access to audit logs
Invalid access attempts
Changes to identification and
authentication mechanisms
Changes to or elevation of
privilege access rights
Initialization, stopping, or
pausing of the audit logs
Creation and deletion of system-
level objects
exceptions
system faults
information security events
system/network events
For each event, the following
details are captured:
Type of event
Time
Where the event occurred
Source of the event
Outcome of the event
(success/failure)
Unique identity of individuals
associated with the event
Identity or name of affected
data, system component, or
resource.
Cyber Security Threat Detection Risk-based monitoring to Risk based monitoring is In-scope
detect unauthorized performed using automated tools
connections, devices, (e.g., SIEM tools) to detect
events, and network unauthorized connections,
services. devices, events, and network
services. Automated tools are
used to perform analysis of
events. Monitoring is performed
in compliance with legal and
regulatory requirements. Events
are analyzed to understand attack
targets and methods.
Cyber Security Threat Detection Automated mechanisms The organization employs In-scope
communicate security automated mechanisms to make
alert and advisory security alert and advisory
information following information available throughout
indicators of the organization when indicators
compromise. of compromise are found.
Cyber Security Threat Response Incident response A formal security incident In-scope
program is in place to response program is established
provide timely and to respond, report, escalate and
effective response to user treat breaches and reported
requests and resolution to security events or incidents. A
all types of incidents. comprehensive incident response
plan exists to identify, manage,
respond to, and recover from
security (e.g., system breach) and
IT operational (e.g., process
errors) incidents and is
communicated to appropriate
stakeholders. The incident
response plan is reviewed and
modified on a periodic basis.
Cyber Security Threat Response Incident response The organization develops, In-scope
program is in place to documents, and disseminate an
provide timely and incident response policy. The
effective response to user policies and procedures are
requests and resolution to reviewed and updated, at a
all types of incidents. minimum, on an annual basis.
Cyber Security Threat Response Security incidents are Incident alert thresholds have In-scope
contained and mitigated been established and all incident
to prevent additional detection tools have been
impact to business calibrated with the thresholds.
operations and loss of Incidents (operational or IT
information. security) are identified, logged,
documented, reported to different
levels within the organization,
and tracked to closure.
Cyber Security Programming Organizations should The organization establishes and In-scope
Security establish and appropriately protects secure
appropriately protect development environments for
secure development system development and
environments for system integration efforts that cover the
development and entire system development
integration efforts that lifecycle.
cover the entire system
development lifecycle.
Cyber Security Programming Systems are developed An established system In-scope
Security securely. development lifecycle (SDLC)
process and methodology is in
place, documented, maintained,
and applied for system and
software design, acquisition,
implementation, configuration,
integration, testing, modification,
and maintenance. The process
also specifies the tools to be used
for system development. The
secure SDLC process,
methodology, and tools are
reviewed on a periodic basis.
Cyber Security Programming Systems are developed The SDLC process is inclusive of In-scope
Security securely. information security
considerations. Security roles and
responsibilities during the
development lifecycle have been
defined. Organization's
information security team and the
risk management methodology is
appropriately integrated into the
SDLC process.
Cyber Security Programming Systems are developed The Security team coordinates In-scope
Security securely. with the system developers to
define and develop system
security plans. System security
plans that outline the security
requirements are documented and
maintained for information
systems. The plans are
communicated to relevant and
authorized internal and external
users.
Cyber Security Programming Test data should be Test data shall be selected In-scope
Security selected carefully, carefully, protected and
protected and controlled. controlled. Operational data is
protected when used for test
purposes. Test data and accounts
are removed from system
components before the system
becomes active/goes into
production.
Cyber Security Programming Applications should be Developers employ secure coding In-scope
Security developed using secure guidelines to software and mobile
coding guidelines, in applications. Developers are
order to address common trained at least annually in up-to-
coding vulnerabilities. date secure coding techniques,
including how to avoid common
coding vulnerabilities. (Refer the
OWASP Guide, SANS CWE Top
25, CERT Secure Coding, etc.)
Cyber Security Programming Production data are not Production data are not used for In-scope
Security used for testing or testing or development.
development.
TABLE 7
Risk Test Type (TBD - As
Category Domain Test Procedure (#) per engagement) Request List (#)
Cyber Cloud Security 1. Obtain and review contracts with cloud Inquiry, Inspection, 1. Contracts with
Security service providers to determine whether contracts and/or observation cloud service
include information security provisions to providers.
protect against cybersecurity and data
security/data privacy risks.
Cyber Cloud Security 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Policies and
Security if all relevant information security requirements and/or observation procedures related to
are established and agreed with each supplier/ contracts between the
vendor that may access, process, store, organization and
communicate, or provide IT infrastructure suppliers/vendors.
components for, the organization's information. 2. Evidence of
2. Inspect a sample of agreements and validate agreements between
that they include the following: the organization and
Roles and responsibilities suppliers/vendors.
Service definitions and SLAs 3. Population -
Information security controls to be System generated list
implemented of contract
System functions, ports, protocols, and other amendments during
services required for the use of such services. the audit period.
Requirement to provide notification of changes 2. Evidence that a new
to services or controls customer or vendor
Requirement to provide notification of 3rd contract addendum or
party personnel transfers and terminations new vendor contract
Laws and regulations that the third party needs was signed for a
to comply with sample of changes to
Penalties or claw back clauses confidentiality
Locations that they can provide services out of commitments
Limitations on data storage locations requiring customer or
Incident management procedures vendor notification.
Breach notification
Right to audit
Limitations and constraints of access
Termination conditions
Data disposal/return upon termination
Ownership of products after development
Quality requirements
Security training requirements for employees
Business-critical or customer-impacting
application design, development, and
deployment
Business-critical or customer-impacting
system designs and configurations design,
development, and deployment
Business-critical or customer-impacting
infrastructure network and system components
design, development, and deployment
IT Governance and service management
policies and procedures
Customer requirements policies and
procedures for service-to-service application
Customer requirements policies and
procedures for information processing,
interoperability, and portability for application
development
Customer requirements policies and
procedures for information exchange, usage, and
integrity persistence
3. Inquire with the control owner to determine if
confidentiality commitments with vendors/
suppliers are changed during the normal course
of business. If changes to confidentiality
commitments are required, verify through
inquiry with the control owner that a vendor
contract addendum or new vendor contract is
established.
4. Obtain the population of tickets related
changes to confidentiality commitments
requiring vendor/supplier notification.
5. For a sample from the above #4 population,
verify that a vendor contract addendum or new
vendor contract was signed.
Cyber Cloud Security 1. Inquire with the control owners and observe Inquiry, Inspection, 1. System and
Security the organization's processes for defining the and/or observation services acquisition
safeguards that protect systems against supply policies and
chain threats, as well as the automated procedures.
mechanisms supporting supply chain threat 2. Procedures for the
safeguards. Determine if the organization integration of security
protects its information systems, system requirements into the
components, or information system services development process.
from supply chain threats by implementing 3. Service delivery
security safeguards as defined by the information agreements
security strategy.
2. Inspect system and services acquisition
policies and procedures, procedures for the
integration of security requirements into the
development process, and supporting
documentation to determine the following:
if the organization defines the security
safeguards to implement as protection to
information systems, system components, or
system services against supply chain threats.
if the organization assures reasonable
information security across their information
supply chain by performing annual reviews,
including reviews of all partners and third-party
providers that the organization's information
supply chain depends on.
3. Inspect service delivery agreements and
determine the following:
that third party service providers are required to
demonstrate compliance with information
security and confidentiality, access control,
service definitions, and delivery-level
agreements defined.
that third-party reports, records, and services
shall undergo audit and review at least annually
to govern and maintain compliance with the
service delivery agreements.
Cyber Cloud Security 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Cloud service
Security the following: and/or observation policies and
The organization uses secure standardized procedures
network protocols (e.g., non-clear text and
authenticated) to manage services.
The organization makes available to
customers documentation detailing relevant
interoperability and portability standards.
If the organization, as a cloud service
provider, uses an industry-recognized
virtualization platform and standard
virtualization format to help ensure
interoperability.
if any custom changes made to any
hypervisor in use and to all solution-specific
virtualization hooks are documented and made
available to customers for review.
2. Inspect cloud service security policies and
procedures and determine the following:
The organization uses secure standardized
network protocols (e.g., non-clear text and
authenticated) to manage services.
The organization makes available to
customers documentation detailing relevant
interoperability and portability standards
The industry-recognized virtualization
platforms and standard virtualization formats are
used to help ensure interoperability.
The custom changes made to any hypervisor
in use and to all solution-specific virtualization
hooks shall be documented and made available
to customers for review.
Cyber Cloud Security 1. Determine through inquiry with control owner Inquiry, Inspection,
Security whether processes are in place to remove any and/or observation
previous content from shared resources when it
is being allocated for reuse to new set of users.
Cyber Data Security 1. Confirm the following have been addressed Inquiry, Inspection,
Security within policies and procedures for the use of and/or observation
electronic communication facilities:
procedures designed to protect exchanged
information from interception, copying,
modification, incorrect routing, and destruction
procedures for the detection of and protection
against malicious code that may be transmitted
through the use of electronic communications
procedures for protecting communicated
sensitive electronic information that is in the
form of an attachment, policy or guidelines
outlining acceptable use of electronic
communication facilities
procedures for the use of wireless
communications, employee, contractor and any
other users' responsibilities not to compromise
the organization, use of cryptographic
techniques, retention and disposal guidelines for
all business correspondence in accordance with
relevant national and local legislation and
regulations, not leaving sensitive or critical
information on printing facilities
controls and restrictions associated with the
forwarding of communication facilities, not
leaving messages containing sensitive
information on answering machines, reminding
personnel not to register demographic data in
any software to avoid collection for unauthorized
use.
Cyber Data Security 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Data Classification
Security whether the business value of each information and/or observation Policy and
asset has been established and documented. procedures.
2. Inquire with the control owner and obtain the 2. Evidence that
Data Classification Guide to determine if critical assets have
classification schemes and procedures for been identified and
handling, processing, storing and communicating documented.
information consistent with its classification, 3. Evidence that the
criticality, and business value are documented. security categorization
3. Inquire with the control owner to determine decision is reviewed
whether critical assets have been identified and and approved by the
documented. authorizing official or
4. Determine whether logical and physical authorizing official
protection levels offered for data stored in designated
databases, removable media, etc. is in alignment representative.
with the classification level of the data. 4. Sample of media to
5. Inspect if the security classification decision is determine whether
reviewed and approved by an authorizing official they have been
or authorizing official designated representative. classified so that
6. Inspect if all media has been classified so that sensitivity of the data
the sensitivity of the data can be determined. can be determined.
7. Validate whether all assets have been assigned 5. Evidence that assets
an owner. are assigned to an
owner.
Cyber Data Security 1. Obtain and inspect relevant documents to Inquiry, Inspection, 1. Account
Security determine if the organization implements various and/or observation Management
data mining protection program for the Procedures.
information system, system component, or 2. Information
information system service. Security technical
For example: standard.
limiting the types of responses provided to 3. Access
database queries; Management
limiting the number/frequency of database procedures.
queries to increase the work factor needed to 4. Database access
determine the contents of such databases; and management
notifying organizational personnel when procedures.
atypical database queries or accesses occur.
2. Inquire with control owners to determine that
established policies and procedures are in place
and define data mining prevention and detection
techniques, define that data storage objects are to
be protected, and define the organization-defined
techniques for data mining prevention and
detection techniques for data storage
3. Inspect the organizations Account
Management Procedures, Information Security
Technical Standard, Access Management
Procedures, Database Access Management
Procedure, and determine that the established
policies and procedures outline and define data
mining prevention and detection techniques and
storage protection:
Cyber Data Security 1. Obtain and inspect relevant documents to Inquiry, Inspection, 1. Relevant policies
Security determine if the organization aligns with its risk and/or observation and procedures.
strategy and risk appetite when implementing 2. Evidence of review
data protection measures. (e.g., sign
2. Inquire with control owners to determine that off/approvals
policies and procedures are in place that documented in policy
prescribe data protection measures based on revisions history).
information classification and risk ranking. 3. Screenshot of the
location of policies
and procedures
showing that they are
available to company
personnel.
4. Evidence showing
that policies are part
of annual security
awareness.
Cyber Data Security 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Relevant policies
Security if information security policies and procedures and/or observation and procedures.
are documented, available and communicated to 2. Evidence of review
personnel on accessible resources (internal (e.g., sign
network, shared drive, etc.). off/approvals
2. Inspect policies and procedures to confirm if documented in policy
they are reviewed/updated at least annually or revisions history).
more frequently if required based on changes in 3. Screenshot of the
the environment. location of policies
3. Security policies and operational procedures and procedures
should address organization-determined areas showing that they are
and best practices, examples include: available to company
Business Continuity/Disaster Recovery; personnel.
Data Protection/DLP; 4. Evidence showing
Access Management; that policies are part
Vendor Management; of annual security
Physical Security; awareness.
SDLC;
Security Awareness training;
Mobile device management;
Legal/regulatory requirements;
System/service acquisition;
User agreements.
Incident Management
Network Security
Configuration Management
Application Security
Cryptography and Key Lifecycle Management
Risk Assessment and Treatment
Data confidentiality, integrity and availability
across multiple system interfaces, jurisdictions,
business functions
Cyber Data Privacy 1. Inquire of management and obtain evidence to Inquiry, Inspection, Special Note:
Security validate whether the organization has capabilities and/or observation Personally identifiable
to prevent or monitor data leaks. information (““PII””)
2. Determine if the organization performs and Protected Health
activities to analyze potential opportunities for Information (““PHI””)
covert channels. If so, determine if testing is fall under ““Customer
performed to identify exploitable channels and Data”” and is thus
the bandwidth associated with those channels. subjected to the
3. Inquire with the control owner to determine if company's data
the above-mentioned capabilities in test classification schema
procedure #1 are aligned with legislative, and controls.
regulatory, or contractual obligations, 1. Data Classification
4. Obtain and inspect policies, procedures, and and Protection
other supporting documentation to validate policies and
whether the aforementioned capabilities in test procedures.
procedure #1 are in place to enable the 2. Policies and
organization to meet their obligations to procedures related to
customers in accordance with contractual Data Loss Prevention
requirements. and the handling of
customer data.
3. Evidence of the
organizations
capabilities to prevent
or monitor data leaks.
4. Evidence that data
loss prevention
processes and
procedures are aligned
with legislative,
regulatory, or
contractual
obligations.
Cyber Data Privacy [General Privacy Requirements; Notice, Choice, Inquiry, Inspection, 1. Privacy policies
Security Consent] and/or observation and procedures
1. Inquire with the control owner and determine regarding
where information security policies and confidentiality and
procedures are documented and available to non-disclosures.
personnel with access to PII on accessible 2. ISMS manual
resources (internal network, shared drive, etc.). (Executive
2. Review policies and procedures to confirm Leadership, CTO)
they are reviewed/updated at least annually or 3. Evidence to
more frequently if required based on changes in demonstrate that
the environment, documents are
3. Inspect the information security policies on available to personnel
the company's internal network and determine with access to PII on
they are available and communicated to accessible resources
company personnel with access to PII and such as internal
include security roles, responsibilities, and network, shared drive,
procedures. Specifically, privacy policies and etc.
operational procedures for the confidentiality 4. Data localization
and non-disclosure agreements. policy
[Storage Location of PII] 5. List of countries
1. Inquire with the control owner and determine that might have access
that the organization has documented data to the organization's
localization policies and procedures available to customers' PII.
personnel on accessible resources (company 6. Evidence
intranet, shared drive). documenting the
2. Inspect the data localization policy on the review and update
company's internal network and determine they procedures performed
are available and communicated to company by the organization to
personnel and address that the organization ensure that the list of
documents and makes available the countries countries is accurate
where PII might be stored as required. and up to date.
3. Inspect policies and procedures to confirm
they are reviewed and updated based on changes
in the environment.
4. Obtain and inspect the list of countries that
might have access to the organization's
customers' PII.
5. Obtain and inspect the list of countries to
determine the review and update procedures
performed by the organization to ensure that the
listing is accurate and up to date.
Cyber Data Privacy 1. Inquire with control owners to understand Inquiry, Inspection, 1. Data privacy policy
Security where, within the organization's data policies, and/or observation showing the
the expectations for the return, transfer, and/or expectations for the
destruction of PII is defined. In addition, return, transfer, and/or
determine how this is communicated to the destruction of PII by
customers (i.e. website, contract/amendments). the organization for
2. Obtain and observe the appropriate the customers.
documentation (i.e. data policy) showing the 2. Data Classification
expectations for the return, transfer, and/or policy for restricted
destruction of PII by the organization for the class protection.
customers.
Cyber Penetration 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Copy of most
Security Testing whether penetration tests are performed on a and/or observation recent penetration test
periodic basis and remediation plans are and penetration test
developed to address the risks. methodology utilized.
2. Inspect the results of the most recent 2. Population of risks
penetration test to determine whether it was from most recent
completed within the organization-specified time penetration test.
period and performed by an independent 3. For a sample of
penetration agent or team. risks, please provide
3. Inspect ticket details and supporting ticket/supporting
documentation for a sample of risks identified in details to document
the most recent penetration test to determine remediation.
whether the risks were remediated or were being 4. Please provide
actively worked to remediation. evidence that both
external and internal
penetration tests are
performed at least
annually and after any
significant
infrastructure or
application
modification.
Cyber Network 1. Inspect documented procedures and determine Inquiry, Inspection, 1. Firewall and router
Security Security that there is a formal process for testing and and/or observation configuration
approval of all: standards
Network connections; and 2. Evidence of
Changes to firewall and router configurations firewall rule review.
2. Obtain a population of changes to network 3. Router rule sets
connections, firewalls, and router configurations. 4. Network diagrams
3. Select samples and obtain tickets. 5. Population of
4. Inspect tickets from selected sample to changes to network
validate that changes to network connections, connections, firewalls,
firewalls, and router configurations were tested and router
and approved. configurations.
5. Validate whether the network diagrams are 6. Tickets for samples
updated if there is a change in the network of changes to network
connection. connections, firewalls,
and router
configurations.
7. Population of
firewall reviews, from
which a sample will
be selected.
8. Evidence of
firewall reviews for
the sample selected.
Cyber Patch and 1. Inquire with the control owner to determine if Inquiry, Inspection, 1. Policies and
Security Vulnerability a formal vulnerability management program and/or observation procedures related to
Management exists and tools are in place to detect, report, and vulnerability
correct vulnerabilities. management.
2. Determine if there is a formally documented 2. Population of
vulnerability management methodology and vulnerability/patch
procedures. tickets.
3. Through interviews with the control owner, 3. Sample evidence of
inspection of reports, determine whether system ticket resolution
vulnerabilities are identified and tracked. including risk ranking.
4. Inspect tickets to determine if the vulnerability 4. Information
was ranked, worked to resolution based on Security Policies and
criticality, authorized, tested, and approved prior procedures.
to implementation into production.
5. Verify whether the program is evaluated on a
quarterly basis.
Cyber Patch and 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Evidence that
Security Vulnerability if vulnerability scans were performed on both and/or observation vulnerability scans
Management external and internal facing production systems were performed on
using internal scanning resources on an both external and
organization-defined frequency. internal facing
2. Inspect the internal scanning resource production systems
configurations and determine vulnerability scans using internal
were scheduled to run with an appropriate scanning resources.
frequency and were configured to run against 2. Scanning resource
internal and external IP ranges. configuration.
3. Inspect the vulnerability scan report for a 3. Reference of
sample of weeks and determine an internal and internal IPs from a
external vulnerability scan was completed in source that is
accordance with the configured schedule. independent from the
4. Inspect if the organization performs privileged/ team responsible for
authenticated vulnerability scans vulnerability scanning
5. Inspect if the organization employs 4. Internal and
vulnerability scanning procedures that can external vulnerability
identify the breadth and depth of coverage (i.e., scan reports for the
information system components scanned and for the selected weeks
vulnerabilities checked). (to be specified).
6. Inspect if the organization employs
vulnerability scanning procedures that updates
the information system vulnerabilities scanned.
Cyber Patch and 1. Determine the number of vulnerabilities Inquiry, Inspection, 1. Obtain a listing of
Security Vulnerability identified. and/or observation application systems
Management 2. Validate that patch management process is with vulnerabilities.
initiated to address the known vulnerabilities. 2. Obtain a listing of
3. Validate that patch is tested and applied timely patches deployed to
to mitigate the known vulnerabilities. address identified
vulnerabilities in a
timely manner.
3. Obtain evidence
showing that the
patches were tested
before deployed into
production
Cyber Threat 1. Inquire with the control owners and inspect Inquiry, Inspection, 1. System generated
Security Detection evidence to validate whether or not the and/or observation list of production
organization performs logging related to both servers and network
unauthorized actions and access. The following devices as of present
items are examples of logging mechanisms that day with source, filter/
should be in place: query details, etc.
Action-related logging events: 2. Log configurations
all changes, additions, or deletions to any for a sample of
account with root or administrative privileges; production servers
Initialization, stopping, or pausing of audit and network devices.
logs; 3. Evidence that the
creation and deletion of system level objects; organization performs
creation, modification, enabling, disabling, and logging related to both
removing of accounts; unauthorized actions
initialization and the stopping or pausing of and access.
audit logs. 4. Policies and
system security configuration changes procedures related to
activation and de-activation of protection access control,
systems (e.g., A/V and IDS) account management,
management activities, system and application audit and
startup/shutdown/errors, file changes, and accountability, storage
security policy changes. engineering, and audit
Access-related logging events: record content.
successful and unsuccessful account logon 5. Evidence that the
events; organization
all individual access to cardholder data; configures
access to all audit trails; information systems
elevation of privileges. to allocate storage
2. Inquire of management and inspect evidence space for the retention
to validate whether the organization: of audit records.
includes user identification, event type, date
and time stamp, indication of success or failure,
event origination, and identity of affected data,
system component, or resources in log entries;
monitors information system accounts for
abnormal usage and activity;
reports abnormal usage and activity on
information system accounts to specified
personnel;
configures information systems to generate
audit records that contain information on what
type of event occurred, when and where the
event occurred, the source and outcome of the
event, and the identity of individuals associated
with the event;
continuously writes logs from production
servers, network devices, databases and storage
management hosts to system logs and forwards
them to the logging and alerting system in real-
time in order to provide backup media for
records other than the audited system;
configures the information system to provide
the capability to generate audit records for
defined auditable events for specified
information system components;
configures the information system to allow
specified personnel to select which auditable
events should be audited by specific system
components;
configures the information system to provide
capabilities for specified individuals to change
the performed audits on information system
components based on defined selectable event
criteria within specified thresholds.
3. Inspect policies and procedures around access
control, account management, audit and
accountability, storage engineering, and audit
record content and validate whether or not the
organization.
defines abnormal information system account
usage and the personnel to be notified upon the
identification of abnormal system usage;
configures the information system to generate
audit records that contain information on what
type of event occurred, when and where the
event occurred, the source and outcome of the
event, and the identity of individuals associated
with the event;
defines the additional detailed information
required to be included in audit records that the
information system generates;
defines the information system components that
provide audit record generating capabilities for
defined auditable events;
defines the personnel whom are allowed to
select which auditable events are to be audited
by specified information system components,
and change the validating performed on specified
information system components;
defines the information system components that
validating is performed on;
defines the time thresholds that must be met for
specified individuals to change the audit
functions performed on information system
components;
defines the event criteria that can be selected by
specified individuals or roles to support the
capabilities of changing audit functions
performed on information system components;
continuously writes logs from production
servers, network devices, databases and storage
management hosts to system logs and forwards
them to the logging and alerting system in real-
time in order to provide backup media for
records other than the audited system
4. Inspect audit record storage capacity related to
information system configuration settings and
determine that the organization configures
information systems to allocate storage space for
the retention of audit records and that it is
sufficient in accordance to defined requirements.
Cyber Threat 1. Inquire with the control owner to determine if Inquiry, Inspection, 1. Evidence that the
Security Detection documented procedures for monitoring are in and/or observation organization monitors
place to detect vulnerabilities, indicators of the Blockchain
potential attacks in accordance with information system to
(organization-defined) monitoring objectives, detect unauthorized/
unauthorized local, network, and remote malicious activity.
connections; 2. Provide a list of
2. Inquire with the control owner to verify tools and processes in
whether monitoring tools are implemented in place to monitor the
high risk systems and environments to detect Blockchain
anomalous events and activities: information system
Inbound and outbound communications and their
Internal system activities, including configurations.
unauthorized system use and transactions 3. Provide a system
Unauthorized connections generated list of
Unauthorized users vulnerability tickets
Unauthorized devices for the period under
Unauthorized software review, from which a
Unauthorized remote access connections sample will be
3. Verify whether action is taken as part of selected.
incident response and vulnerability management 4. Provide the internal
plan when anomalous events are detected tickets from the
4. Inspect the monitoring tools to verify their selected sample.
configuration and validate whether they are
configured to detect anomalous events.
Cyber Threat 1. Inquire with management to determine if the Inquiry, Inspection, 1. Information
Security Detection organization employs automated mechanisms to and/or observation security policies and
make security alert and advisory information procedures related to
available throughout the organization. security alerts and
2. Inspection information security policies to advisories.
determine if the organization has defined 2. Evidence of
requirements regarding automated mechanisms processes in place for
to make security alert and advisory information defining, receiving,
available throughout the organization. generating, and
3. Inspect organizational processes in place for disseminating security
defining, receiving, generating, and alerts and advisories.
disseminating security alerts and advisories,
including automated mechanisms supporting
and/or implementing dissemination of security
alerts and advisories.
Cyber Threat 1. Verify that a formal incident response Inquiry, Inspection, 1. Information
Security Response program exists and includes formally defined and/or observation Security Incident
roles and responsibilities, an incident response Management
plan, and resources to support incident response. documentation
2. Obtain the copy of the incident response plan. 2. CSIRT/Incident
Verify that it is formally documented and has Response Plan
been approved by a senior Management 3. CSIRT/Incident
executive. Response Process
3. Validate that the incident response plan 4. Provide
document has been recently (within the last year) documentation for
reviewed and the latest plan has been shared with previously reported
and communicated to personnel with incident incidents or alerts.
response responsibilities.
4. Verify whether the incident response plans
covers both IT operational and security
incidents.
5. Verify that the incident response plan contains
the following:
Roles and responsibilities, and structure and
organization of the incident response capability;
Incident response process flows and procedures
that include steps for preparation, detection and
analysis, containment, eradication, and recovery;
Defines reportable incidents and incident
classification;
Incident communication and notification;
Analysis of legal requirements for reporting
compromises;
Provides metrics for measuring the incident
response capability within the organization;
Defines the resources and management support
needed to effectively maintain and mature an
incident response capability;
System and data recovery;
Data backup processes.
6. Verify if the incident response plan is
periodically updated to address
system/organizational changes or problems
encountered or lessons learned during plan
implementation, execution, training, or testing.
7. Review documentation from a sample of
previously reported incidents or alerts to verify
that the documented incident response plan and
procedures were followed.
Cyber Threat 1. Inquire with control owner to determine if the Inquiry, Inspection, 1. CSIRT Incident
Security Response organization develops, documents, and and/or observation Response Plan
disseminate an incident response policy. 2. Security Incident
2. Examine the incident response plan to Response Process
determine if an incident response policy exists 3. Corporate Critical
and whether the policy address the specific Incident Process
purpose, scope, roles and responsibilities, 4. Information
management commitment, and compliance. Security Policies
3. Examine the information security policies and 5. Crisis Management
procedures (see evidence), CSIRT Incident Team Plan
Response Plan, Security Incident Response
Process, Corporate Critical Incident Process and
determine if the incident response procedures are
disseminated to appropriate personnel.
4. Observe location of incident response plan on
the organization intranet (or other location) to
determine how the incident response policies are
disseminated.
5. Examine the incident response plan to
determine if the organization has reviewed and
updated on an annual basis.
Cyber Threat 1. Inquired of the control owner to determine Inquiry, Inspection, 1. Listing of recent
Security Response whether security incidents were tracked and and/or observation incidents for the
documented from initiation through closure. period under review
2. Obtain a listing of incidents for the period and parameters/query
under review and select an appropriate number used to generate the
of samples. report.
3. Obtain tickets or documentation to validate 2. Documentation of
that the incidents were documented incident containment
(categorized/prioritized), reviewed, tracked and and mitigation, such
resolved in a timely manner and includes the as IT tickets.
following details:
The identified solutions or workaround are
documented, applied and tested, and recovery
actions are performed to restore the IT-related
service.
The satisfactory resolution of incidents and/or
request fulfillment is verified and is closed.
4. Determine whether incident thresholds have
been established and whether the tools have been
calibrated with the thresholds.
Cyber Programming 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Information
Security Security whether the organization establishes guidelines and/or observation Security Policies
for the secure development environment for containing technical
critical systems. roles that address
2. Inspect the information security policies to development
determine whether the policies outline guidance activities, and
for technical roles and secure development established guidelines
environment for critical systems. for the secure
3. Validate whether management reviewed the development
policy within the past 12 months and environment for
communicated it to employees. critical systems.
4. Review the secure development standards to 2. Evidence that
validate whether appropriate measures have been management reviewed
described for security of development the Information
environments. Security Policies
5. Review the access list for a sample of within the past 12
development environments and validate whether months and
the access has been approved. Also validate communicated it to
whether any non-developers have access to the employees.
development environment.
Cyber Programming 1. Inquire with control owner to whether an Inquiry, Inspection, 1. SDLC policies and
Security Security established system development lifecycle and/or observation procedures.
process is in place, documented, maintained, and 2. Evidence that an
applied for all system and software design, established system
acquisition, implementation, configuration, development lifecycle
integration, testing, modification, and process is in place,
maintenance. documented,
2. Obtain and inspect SDLC policies and maintained.
procedures to determine whether an established 3. Security
system development lifecycle process is requirements for
documented. information systems
3. Verify whether security requirements for and information
information systems and information services are services are identified
identified as part of SDLC efforts, business
process re-design, etc.
Cyber Programming 1. Obtain the SDLC process/methodology Inquiry, Inspection, 1. Policy for the
Security Security documentation and verify whether it specifies and/or observation SDLC process
that the developers should consider information 2. System and
security during the requirements gathering, high Services Acquisition
level design, low level design, development, and Policies, Procedures
systems integration phases of developing an and Standards
information system. 3. Information
2. Verify whether the SDLC Security Procedures
process/methodology documentation specifies (SDLC process)
whether the testing phase should include security
testing of information systems.
3. Verify that during the functional requirements
gathering phase, the information security
requirements are captured and consider the
following:
the level of confidence required towards the
claimed identity of users, in order to derive user
authentication requirements
access provisioning and authorization
processes
required protection needs of assets involved
requirements derived from business processes,
such as transaction logging and monitoring, non-
repudiation requirements
requirements mandated by other security
controls, e.g., interfaces to logging and
monitoring or data leakage detection systems
information users and operators of their duties
and responsibilities
4. Verify whether the SDLC
process/methodology defines the security roles
and responsibilities during the development
lifecycle.
5. Verify whether there is a clear integration
between the organization risk management
methodology and SDLC methodology and
whether it outlines how information systems can
be classified based on their inherent risk.
Cyber Programming 1. Inspect if the organization: Inquiry, Inspection, 1. Security program
Security Security Develops a security plan for the information and/or observation plans, budget,
system that: procedures, and
Is consistent with the organization's enterprise policies
architecture 2. Information
Explicitly defines the authorization boundary Security Governance
for the system; Program
Describes the operational context of the documentation
information system in terms of missions and
business processes;
Provides the security categorization of the
information system including supporting
rationale;
Describes the operational environment for the
information system and relationships with or
connections to other information systems;
Provides an overview of the security
requirements for the system;
Identifies any relevant overlays, if applicable;
Describes the security controls in place or
planned for meeting those requirements
including a rationale for the tailoring decisions;
and
Is reviewed and approved by the authorizing
official or designated representative prior to plan
implementation;
Distributes copies of the security plan and
communicates subsequent changes to the plan to
organization-defined personnel or roles;
Reviews the security plan for the information
system per organization-defined frequency;
Updates the plan to address changes to the
information system/environment of operation or
problems identified during plan implementation
or security control assessments; and
Protects the security plan from unauthorized
disclosure and modification.
2. Inspect if the organization.
Identifies organization-defined user actions that
can be performed on the information system
without identification or authentication
consistent with organizational missions/business
functions; and
Documents and provides supporting rationale
in the security plan for the information system,
user actions not requiring identification or
authentication.
Cyber Programming 1. Inquire with control owner/interview Inquiry, Inspection, 1. Provide written
Security Security responsible personnel to understand how and/or observation software-development
production data is sanitized, transferred, and procedures.
used for test purposes. 2. Provide a
2. Obtain and inspect written software- population of project
development procedures to verify that plans/checklists, from
operational data is sanitized, transferred, when which a sample will
used for test purposes. be selected.
3. Observe testing processes and interview 3. Provide the project
personnel to verify operational data is protected plans and checklists
through testing. for the sample
4. Obtain a population of project plans/checklists selected.
for the period under review. [PCI]
5. Select a sample of project plans and checklists 1. Provide a
to determine whether data protection activities population of data and
are built into the overall test approach. accounts from
production systems
recently installed or
updated for the period
under review, from
which a sample will
be selected.
2. Provide supporting
evidence for the
selected sample of
data and accounts
from production
systems.
Cyber Programming 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Secure Coding
Security Security the following: and/or observation Guidelines;
that documented software and mobile secure Infrastructure
coding guidelines are available to outline Hardening Guidelines
development and implementation guidance for and Secure Coding
software and mobile code Guidelines.
that the organization authorizes, monitors, and 2. System and
controls mobile code use within the information Communications
system Protection Policies
2. Inspect the Secure Coding Guidelines and and procedures
determine that acceptable and unacceptable
software and mobile coding guidelines along
with implementation guidance are outlined
within the documents, including:
a. Secure coding techniques training is
required for developers at least annually, based
on industry best practices and guidance;
b. Software-development process procedures:
defines software-development processes
based on industry standards and leading practices
defines information security throughout
the software development lifecycle
defines that developers must develop
software applications in accordance with
standards
determine that the software-development
standards are implemented.
c. Injection flaws:
Validate inputs to determine that user data
cannot modify meaning of commands and
queries.
Utilizing parameterized queries.
d. Buffer overflows:
Validate buffer boundaries.
Truncating input strings.
e. Insecure cryptographic storage
Prevent cryptographic flaws.
Use strong cryptographic algorithms and
keys.
f. Insecure communication
Determine that insecure communications
are addressed by coding techniques that properly
authenticate and encrypt all sensitive
communications.
g. Improper error handling
Validate that improper error handling is
addressed by coding techniques that do not leak
information via error messages
h. All “high risk” vulnerabilities identified in
the vulnerability identification process
Verify that coding techniques address any
“high risk” vulnerabilities that could affect the
application
i. Cross-site scripting (XSS)
Validating all parameters before inclusion
Utilizing context-sensitive escaping
j. Improper Access Control
Proper authentication of users
Sanitizing input
Not exposing internal object references to
users
User interfaces that do not permit access
to unauthorized functions.
k. Cross-site request forgery (CSRF) to
determine that cross-site request forgery (CSRF)
is addressed by coding techniques that ensure
applications do not rely on authorization
credentials and tokens automatically submitted
by browsers.
1. Broken authentication and session
management:
Flagging session tokens (for example
cookies) as “secure”
Not exposing session IDs in the URL
Incorporating appropriate time-outs and
rotation of session IDs after a successful login.
3. Inspect system and communications protection
policy and procedures addressing mobile code
and determine the following:
that the organization defines the mobile code
and mobile code technologies that are acceptable
and unacceptable;
that the organization establishes restrictions for
acceptable mobile code and mobile code
technology use;
that the organization documents
implementation guidance for the defined
acceptable mobile code and code technologies.
4. Observe the organization's defined processes
for controlling, authorizing, monitoring, and
restricting mobile code and determine that the
organization authorizes, monitors, and controls
mobile code use within the information system.
Cyber Programming 1. Inquire with the control owners and determine Inquiry, Inspection, 1. Policies and
Security Security if procedures clearly define that production data and/or observation procedures related to
(live PANs) are not used for testing or production data (live
development. PANs).
2. Observe the testing processes and determine 2. Population of data
that the organization's personnel do not use and accounts from
production data (live PANs) in testing or in recently installed or
development. updated production
3. Obtain a population of data and accounts from systems.
recently installed or updated production systems. 3. Sample of test data
4. Select a sample of data and accounts and and accounts from the
inspect test data to determine whether production obtained population.
data (live PANs) are used for testing or
development.
In some embodiments, infrastructure layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain infrastructure stack/layer supporting functioning of the underlying hardware, software, servers, databases, networks, interfaces technologies (e.g. APIs etc.).
The sub-risk categories, control and testing objectives, test procedures and request lists for Infrastructure Layer risk category are provided below in Tables 8-10.
TABLE 8
Risk Level (L,
Risk Risk M, H) (As
Risk Category Domain Classification Number Risk Description applicable)
Infrastructure Layer Servers and Strategic, IL-SD1 Lack of guidance and policy of L, M, H
Databases Operational, functional requirements and
Configuration Financial, migration to production may lead
Compliance, to inaccurate Blockchain logic.
Legal, or
Reputational
Infrastructure Layer Servers and Strategic, IL-SD2 Lack of an established baseline L, M, H
Databases Operational, for information technology
Configuration Financial, systems and Blockchain may
Compliance, affect operational environments
Legal, or and compromise security.
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT1 Unauthorized or untested L, M, H
Operational, changes, or the failure to make
Financial, necessary changes to operating
Compliance, system, network or application
Legal, or configurations or programs
Reputational prevent systems from processing
transaction records completely
and accurately
Infrastructure Layer ITGCs Strategic, IL-IT2 Lack of segregation for roles L, M, H
Operational, and responsibilities and instance
Financial, environments may lead to
Compliance, unauthorized changes to
Legal, or productions.
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT3 Lack of segregation for roles L, M, H
Operational, and responsibilities and instance
Financial, environments may lead to
Compliance, unauthorized changes to
Legal or productions.
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT4 Transaction records are lost L, M, H
Operational, (e.g. due to system failure)
Financial, and data is not recoverable or
Compliance, is corrupted/duplicated in the
Legal, or recovery process
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT5 Transaction records transferred L, M, H
Operational, between systems are incomplete
Financial, or inaccurate.
Compliance,
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT6 As business processes are L, M, H
Operational, redesigned and modified to reflect
Financial, use of Blockchain technology,
Compliance, they embed an agreed set of
Legal, or appropriate controls
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT7 Application end-users bypass L, M, H
Operational, systems-enforced authorization
Financial, and segregation of duties controls
Compliance,
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT8 Application end-users bypass L, M, H
Operational, systems-enforced authorization
Financial, and segregation of duties controls
Compliance,
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT9 High-risk/powerful accounts L, M, H
Operational, (e.g., super-user, etc.) bypass
Financial, systems-enforced authorization
Compliance, and segregation of duties
Legal, or controls
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT10 Unauthorized access to facilities, L, M, H
Operational, equipment and resources is not
Financial, prevented
Compliance,
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT11 Unauthorized access (by L, M, H
Operational, business users, IT users or
Financial, outsiders) to data causes data
Compliance, destruction or improper
Legal, or amendment of records.
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT12 Unauthorized access (by L, M, H
Operational, business users, IT users or
Financial, outsiders) to data causes data
Compliance, destruction or improper
Legal, or amendment of records.
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT13 Duties are not appropriately L, M, H
Operational, segregated
Financial,
Compliance,
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT14 Weak password controls or L, M, H
Operational, security configurations allow
Financial, access rights to be circumvented
Compliance,
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT15 Unauthorized access (by L, M, H
Operational, business users, IT
Financial, users or outsiders) to
Compliance, Blockchain Operational
Legal, or governance tools.
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT16 Unauthorized or untested L, M, H
Operational, changes, or failure to make
Financial, necessary changes to scheduled
Compliance, job processes prevent systems
Legal, or from processing transaction
Reputational records completely and
accurately
Infrastructure Layer ITGCs Strategic, IL-IT17 Unauthorized or untested L, M, H
Operational, changes, or failure to make
Financial, necessary changes to scheduled
Compliance, job processes prevent systems
Legal, or from processing transaction
Reputational records completely and
accurately
Infrastructure Layer ITGCs Strategic, IL-IT18 Blockchain processing errors L, M, H
Operational, are not resolved.
Financial,
Compliance,
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT19 Unauthorized access to the L, M, H
Operational, Blockchain technology (i.e.
Financial, code configuration tools) is
Compliance, prevented.
Legal, or
Reputational
Infrastructure Layer ITGCs Strategic, IL-IT20 Management release L, M, H
Operational, management policies and
Financial, procedures include processes
Compliance, for making emergency
Legal, or configuration changes, including
Reputational formal review processes for
all changes categorized as
emergency.
Infrastructure Layer ITGCs Strategic, IL-IT21 Unauthorized or untested L, M, H
Operational, changes, or failure to make
Financial, necessary changes to scheduled
Compliance, job processes prevent systems
Legal, or from processing transaction
Reputational records completely and
accurately
Infrastructure Layer Business Strategic, IL-BC1 A lack of backups or ineffective L, M, H
Continuity and Operational, backups may lead to information
Disaster Financial, loss.
Recovery Compliance,
Legal, or
Reputational
Infrastructure Layer Business Strategic, IL-BC2 Lack of Business Continuity L, M, H
Continuity and Operational, and Disaster Recovery plans
Disaster Financial, may inhibit the organization's
Recovery Compliance, ability to recover from an outage.
Legal, or
Reputational
Infrastructure Layer Business Strategic, IL-BC3 A lack of backups or ineffective L, M, H
Continuity and Operational, backups may lead to information
Disaster Financial, loss.
Recovery Compliance,
Legal, or
Reputational
Infrastructure Layer Business Strategic, IL-BC4 Lack of Business Continuity L, M, H
Continuity and Operational, and Disaster Recovery plans
Disaster Financial, may inhibit the organization's
Recovery Compliance, ability to recover from an
Legal, or outage.
Reputational
Infrastructure Layer Business Strategic, IL-BC5 A lack of Business Continuity L, M, H
Continuity and Operational, plan and Disaster Recovery plan
Disaster Financial, testing may result in an effective
Recovery Compliance, or failed recovery process.
Legal, or
Reputational
Infrastructure Layer Business Strategic, IL-BC6 Lack of communication to key L, M, H
Continuity and Operational, stakeholders regarding their
Disaster Financial, responsibilities may result in
Recovery Compliance, ineffective recovery activities in
Legal, or the event of an outage.
Reputational
Infrastructure Layer IT Asset Strategic, IL-IT1 Without clearly defined roles L, M, H
Management Operational, and responsibilities with
Financial, Blockchain vendors,
Compliance, accountability is lost when
Legal, or issues arise within
Reputational the relationship
Infrastructure Layer IT Asset Strategic, IL-IT2 Without clearly defined roles L, M, H
Management Operational, and responsibilities with
Financial, Blockchain vendors,
Compliance, accountability is lost when
Legal, or issues arise within the
Reputational relationship
Infrastructure Layer IT Asset Strategic, IL-IT3 Without a comprehensive due L, M, H
Management Operational, diligence process, vendor risks
Financial, may not be completely identified,
Compliance, leaving the organization
Legal, or susceptible to direct and indirect
Reputational risks.
Infrastructure Layer IT Asset Strategic, IT-IL4 Without clearly defined roles L, M, H
Management Operational, and responsibilities with
Financial, Blockchain vendors,
Compliance, accountability is lost when
Legal, or issues arise within the
Reputational relationship
Infrastructure Layer IT Asset Strategic, IL-IT5 Lack of required level of L, M, H
Management Operational, throughput and performance
Financial, can compromise Blockchain
Compliance, use cases objectives.
Legal, or
Reputational
Infrastructure Layer IT Asset Strategic, IL-IF1 Data exchanged through APIs, L, M, F
Management Operational, system interfaces may be
Financial, intercepted and accessed by
Compliance, unauthorized agents within or
Legal, or outside the organization's
Reputational network
TABLE 9
In-scope/Out-
of-Scope
(TBD-As per
Risk Category Domain Control/Test Objective Control Description engagement)
Infrastructure Servers and References to internal and external Once the Blockchain has been In-scope
Layer Databases sources (including interaction with configured, a test plan is
Configuration external platforms, systems, developed to ensure meeting
networks, and third parties) in the all functional requirements
Blockchain logic are accurate. and approved by the
Blockchain program
management. The Blockchain
configurations are tested by
the impacted/required
business and/or the
Blockchain program
management team. Test
exceptions are appropriately
recorded, monitored and
tracked for resolution prior to
migration to production
Infrastructure Servers and A baseline configuration of A configuration management In-scope
Layer Databases information technology systems program and database exists
Configuration and Blockchain is created, to implement, maintain and
implemented, control configuration of
and maintained systems and other
infrastructure elements.
Infrastructure ITGCs Change Management controls are Changes to Blockchain In-scope
Layer defined, established, and enforced Application and Operating
including proper documentation System/Network
and approval configurations and
enhancements are adequately
tested and approved before
being migrated into
production and are monitored
for appropriateness.
Infrastructure ITGCs Segregation of Duties is maintained Access to migrate the In-scope
Layer and enforced for any changes, in Blockchain process
addition the development, test, and configurations into production
production environments are is restricted to personnel who
separated. are independent of the
configuration team.
Development, testing, and
production environments are
segregated for changes to
application configurations and
periodically reviewed to
ensure access is restricted to
authorized personnel.
Infrastructure ITGCs Segregation of Duties is maintained Policies are maintained for In-scope
Layer and enforced for any changes. segregation of duties within
IT
Infrastructure ITGCs Backups of information are Data is appropriately backed In-scope
Layer conducted, maintained, and tested up and recoverable
periodically.
Infrastructure ITGCs Information input and output Errors in production In-scope
Layer checks are performed. processing are identified and
resolved
Infrastructure ITGCs Change Management controls are For each new Blockchain In-scope
Layer defined, established, and enforced business process the
including proper documentation associated controls are
and approval, documented and approved by
the business and the
Blockchain program
management.
Infrastructure ITGCs Access permissions are revoked Terminated employee's/third In-scope
Layer based upon access reviews and/or party or employee's/third
user terminations. party access no longer needed
to Blockchain, database, and
operating system/network is
disabled and/or removed in a
(timely manner).
Infrastructure ITGCs Access to systems and assets is Access requests to the In-scope
Layer controlled by incorporating the application, database, and
principle of least privilege. operating system/network are
properly reviewed and
authorized by management
Infrastructure ITGCs Privileged user roles and Super-user/administrative In-scope
Layer responsibilities are managed and application, database, and
tracked. operating system/network
transactions or activities and
sensitive generic IDs are
monitored
Infrastructure ITGCs Physical access controls are in place Employees', contractors', and In-scope
Layer to properly authorize employees, visitors' access to data
contractors, and visitors to facilities, center/facility and the
equipment and resources, information system
components located within the
facility is provided on a ‘need
to know’ basis and requires
organizational approval.
Infrastructure ITGCs Physical access to the secure areas There is physical security in In-scope
Layer are monitored. place over the data center
from which financially
significant applications are
run.
Key card system is
implemented in the data
center for access control. And
video surveillance is also in
place to monitor the activities
in the data center.
The key card system logs the
visit to the data center per
user and ID card.
If any incident happens, IT
department will look into the
system log and video footage
for investigation.
Infrastructure ITGCs Access permissions are reviewed Data Center Operations In-scope
Layer periodically for appropriateness. performs a semi-annual
recertification of all users
with physical access to Data
Centers
Infrastructure ITGCs Segregation of Duties is maintained Policies and procedures are In-scope
Layer and enforced for critical business maintained for segregation of
processes and in production duties within IT
environments.
Infrastructure ITGCs Access to applications, database, Passwords to applications, In-scope
Layer operating system and network is database/data file, operating
password protected on a global system/network, and security
level and complies with configurations are set in an
documented policies or working effective manner
practices detailing password
configurations and configurable
security parameters.
Infrastructure ITGCs Access to the Blockchain Access to the Blockchain In-scope
Layer Operational governance tools is operational governance tools
restricted to appropriate personnel. is recertified by appropriate
management at regular
intervals as defined by policy
guidelines. The approver
confirms access remains
commensurate with the
individual's job
responsibilities or requests
changes/revocation to access.
Infrastructure ITGCs As changes to the Blockchain are The Blockchain policies and In-scope
Layer contemplated, appropriate controls procedures on change
are in place to ensure that they are approval and propagation
approved and rolled out across the across the network are defined
network in a manner consistent and include a description of
with the Blockchain governance key controls, oversight and
framework. escalation procedures.
Infrastructure ITGCs As changes to the Blockchain are Only approved and tested In-scope
Layer contemplated, appropriate controls changes are made to the job
are in place to ensure that they are scheduler and rolled out
approved and rolled out across the across the network in a
network in a manner consistent manner consistent with the
with the Blockchain governance Blockchain governance
framework. framework.
Infrastructure ITGCs Formal policies and procedures The Blockchain management In-scope
Layer have been established to identify has a documented problem
the Blockchain processing errors. management process for the
Blockchain configurations
during which errors or
exceptions are identified,
tracked, escalated, root causes
identified and resolved.
Infrastructure ITGCs Access permissions are revoked Access to the Blockchain In-scope
Layer based upon access reviews and/or configuration tools is
user terminations, recertified by appropriate
management at regular
intervals as defined by policy
guidelines. The approver
confirms access remains
commensurate with the
individual's job
responsibilities or requests
changes/revocation to access.
Infrastructure ITGCs Change Management controls are The formal policies and In-scope
Layer defined, established and enforced procedures include detailed
including proper documentation processes and required
and approval approvals necessary to make
an emergency change to the
Blockchain configuration. A
formal review is conducted
for all emergency changes to
ensure proper protocol and
SODs were followed.
Infrastructure ITGCs Consideration of Blockchain has Prior to a Blockchain change In-scope
Layer been incorporated into ongoing being placed into production,
business operations procedures, operations policies and
forms and processes. procedures have been updated
to include integration with
Blockchain to ensure the
business end users are aware
of the Blockchain impact.
Infrastructure Business Upon identified of a processing Back out plans for Blockchain In-scope
Layer Continuity and error, management enables back configuration and plan to roll
Disaster Recovery out/back up plan including the over to human processors in
Blockchain being removed from case of a Blockchain failure
production. are formally documented for
each Blockchain
configuration and routinely
reviewed to ensure still
complete and accurate
Infrastructure Business IT disaster recovery and business Disaster recovery plan for the In-scope
Layer Continuity and continuity plans have been Blockchain technology exists
Disaster Recovery developed based on the framework for prolonged outages (with
and designed to reduce the impact internal systems or 3rd party
of a major disruption on the vendors) and has been tested
Blockchain functions and processes. to limit impact business
The plans are based on risk operations.
understanding of potential business
impacts and address requirements
for resilience, alternative processing
and recovery capability of all
critical IT services including the
Blockchain use case. The plan is
tested on a semi-annual basis.
Infrastructure Business Backups of information are The Blockchain configuration In-scope
Layer Continuity and conducted, maintained, and tested tools and data is included in
Disaster Recovery semi-annually management standard backup
and recovely plan to ensure
data is backed up within data
centers or the cloud and
available if needed.
Infrastructure Business IT disaster recovery and business Risks to business continuity In-scope
Layer Continuity and continuity plans have been due to prolonged outages
Disaster Recovery developed based on the framework (with internal systems or with
and designed to reduce the impact 3rd party vendor) have been
of a major disruption on the identified and procedures
Blockchain Instance functions and have been formally
processes. The plans are based on documented to mitigate any
risk understanding of potential risks.
business impacts and address
requirements for resilience,
alternative processing and recovely
capability of all critical IT services
including the Blockchain use case.
The plan is tested on a semi-annual
basis.
Infrastructure Business Business Continuity and Disaster Business Continuity and In-scope
Layer Continuity and Recovery plans are tested semi- Disaster Recovery plans are
Disaster Recovery annually to validate that the plans tested semi-annually to verify
meet the organizational the validity of established and
requirements. implemented information
security controls and to take
appropriate corrective actions.
Infrastructure Business Recovery activities are Communication occurs to the In-scope
Layer Continuity and communicated to internal individuals and teams
Disaster Recovery stakeholders and executive and involved in the recovery plan
management teams prior to and to ensure key stakeholders
during declared outages. understand their
responsibilities in the event of
an outage.
Infrastructure IT Asset The Blockchain vendors are The Blockchain vendors are In-scope
Layer Management monitored for compliance with monitored on an ongoing
contractual agreements. basis to ensure compliance
with contractual agreements.
Infrastructure IT Asset Licensing agreements are The Blockchain licensing In-scope
Layer Management monitored and renewed as needed. agreements are reviewed,
tracked and renewed as
needed.
Infrastructure IT Asset The Blockchain program policies The Blockchain vendor In-scope
Layer Management and procedures, which includes selection was based on formal
formal the Blockchain vendor selection methodology and
selection methodology and detailed business
standard contract templates and requirements.
requirements, are reviewed and
approved on a periodic basis.
Infrastructure IT Asset The Blockchain program policies The Blockchain vendor In-scope
Layer Management and procedures, which includes contracts clarifies resource
The Blockchain contract policies ownership and hardware
including clarification of the procurement requirements for
Blockchain ownership, are client and vendor.
reviewed and approved on a
periodic basis.
TABLE 10
Test Type (TBD-
Risk Category Domain Test Procedure (#) As per engagement) Request List (#)
Infrastructure Servers and 1. Inquire with the control owners to Inquiry, Inspection, 1. Policies and procedures
Layer Databases determine if the organization and/or observation related to configuration
Configuration identifies and documents established settings, specifically regarding
configuration settings. Review the test plan of all functional
existing documentation around test requirements for configuration.
exceptions to ensure the test plans 2. Log of test exceptions.
identifies all functional requirements.
2. Verify the test exceptions are
recorded, monitored and tracked for
resolution prior to migration to
production
Infrastructure Servers and 1. Verify whether a configuration Inquiry, Inspection, 1. Policies, procedures, related
Layer Databases management program is documented and/or observation to the baseline configuration
Configuration and maintained settings on production
infrastructures.
Infrastructure ITGCs 1. Inquire with the control owner and Inquiry, Inspection, 1. Change Management
Layer determine that the organization has a and/or observation policies, procedures, and
documented Change Management standards
Process and it is reviewed at least 2. Evidence of the last review
annually and updated as needed. of documented Change
2. Obtain a list of changes that were Management Process.
migrated to production for the testing 3. Population of changes for
period. the applications and systems
3. Select a sample of changes made to 4. Evidence of change requests
the production environment and and approvals
determine if it was documented,
tested prior to migration to
production, and approved by the
appropriate personnel.
4. Inspect that appropriate SOD is
implemented for roles and
environments.
Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Screen-prints for each of the
Layer determine that the development/ and/or observation following environments:
testing environments are separate development
from the production environment. testing
2. Obtain and inspect screen-prints of production
the development, testing, and 2. Evidence of access control
production environment to determine settings to enforce separation
that they are in different between development/testing
environments. and production environments.
Infrastructure ITGCs 1. Determine through interviews with Inquiry, Inspection, 1. Evidence of segregation of
Layer control owners whether access and/or observation duties in place for each in-
controls are defined, documented, scope information system.
approved and enforced for changes to
information systems.
Infrastructure ITGCs 1. Inspect relevant backup Inquiry, Inspection, 1. Backup policies and
Layer documentation and inquire with the and/or observation procedures
control to validate whether the 2. Screenshot of backup
following considerations have been configuration settings
determined, documented, and 3. Backup log showing status
implemented. of backups
2. Inspect the backup confirmation 4. Evidence of successful
settings and frequency to determine backup restoration
whether it is in accordance with 5. Reports detailing testing
policies and procedures. efforts and the results of the
3. Review activity logs for backups to testing efforts
determine the completeness of the 6. Evidence of backup
organizations backup efforts. schedule
4. Review activity logs for backups to
determine if an alert is configured to
notify administrators of successful
and failed backups.
5. Review detailing testing efforts and
the results of the testing efforts.
Infrastructure ITGCs 1. Inquire with management to Inquiry, Inspection, 1. Provide the input validation
Layer determine if the production systems and/or observation rules/configuration on the
and applications have built in production systems and
detective alerts if an invalid input is applications.
received and an error message is
generated.
2. Inspect the input validation rules
and program logic on the production
systems and applications to determine
if input validation checks are
appropriately configured to validated
information entered into a data field.
Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Blockchain use case risk and
Layer determine the review and approval and/or observation control matrix with approval
process for additional controls from a
redesign.
2. Review an updated risk and control
matrix and inspect for evidence of
approval
Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Information Security Policy
Layer determine whether the organization and/or observation of Access
revokes user account access in Provisioning/Deprovisioning
response to terminations. Policy
2. Obtain and inspect policies and 2. Population of total
procedures to determine the terminated users
requirements are clearly stated for the 3. Evidence that access is
removal of logical access as a result revoked within the timeframe
of terminations. specified by the access control
3. Select a sample of terminated users procedures
and inspect the evidence to determine
that access is revoked within the
timeframe specified by the access
control procedures.
Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Information Security Policy
Layer determine the review and approval and/or observation of Access
process for access requests. Provisioning/Deprovisioning
2. Obtain the population of access Policy
requests and inspect the evidence to 2. User access requests
determine that access is properly 3. Evidence that access is
reviewed and approved by reviewed and approved by
management. management
Infrastructure ITGCs 1. Inquire with control owners who is Inquiry, Inspection, 1. Information Security Policy
Layer responsible for assigning access to and/or observation of Access
verify that access to privileged user Provisioning/Deprovisioning
IDs are appropriate and restricted. Policy
2. Obtain and inspect documentation 2. Population of users with
to determine that privileged access privileged access
requests are evaluated for 3. Evidence for selected
appropriateness and follow the samples, indicating the job
principles of least privilege. function(s) or role(s)
3. Obtain a population of users with requested, as well as the
privileged access and select a sample approval for the access
of users and inspect evidence to requested.
determine the access is necessary and 4. List of privileged user
approved by the designated authority. accounts and associated roles.
5. Access approval matrix
Infrastructure ITGCs 1. Inquire with management and Inquiry, Inspection, 1. Physical access policies and
Layer inspect the documented process to and/or observation procedures
determine if procedures are defined 2. Populationof new users
for authorizing and granting physical 3. Access lists to in-scope
access to employees, contractors, and facilities and equipment
visitors based on role or function.
2. Obtain a population of new users
who have been granted access to the
in-scope facilities and equipment.
3. Select a sample of new users and
inspect that physical access was
authorized and documented prior to
physical access granted.
Infrastructure ITGCs 1. Inquire with management the key Inquiry, Inspection, 1. Key card system
Layer card system implementation process. and/or observation implementation policy
2. Inquire/Observe with management 2. Key card system access list
that video surveillance is in place at 3. Key card system logs to the
the data centers. data centers
3. Obtain the key card system logs to
the data centers.
4. Select a sample of users granted
access to the data center and inspect
that key card access was authorized
and documented prior to physical
access granted.
Infrastructure ITGCs 1. Obtain the key card system log to Inquiry, Inspection, 1. Key card system logs to the
Layer the data center operations and select a and/or observation data center operations
sample of users to inspect the 2. Evidence of recertifications
recertification occurs on a semi- for users with physical access
annual basis.
Infrastructure ITGCs 1. Determine through interviews with Inquiry, Inspection, 1. Evidence of segregation of
Layer control owners whether access and/or observation duties in place for each in-
controls are defined, documented, scope information system.
approved and enforced for changes to
information systems and critical
business processes.
Infrastructure ITGCs 1. Examine the documentation and Inquiry, Inspection, 1. Screenshots of password
Layer security parameters to verify they are and/or observation configurations
aligned 2. Password policy
Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Information Security Policy
Layer determine that the organization has a and/or observation of Access
documented recertification policy and Provisioning/Deprovisioning
it is reviewed at least annually and Policy
updated as necessary. 2. Evidence of recertifications
2. Select a sample of recertifications for the Blockchain Operational
for the Blockchain Operational governance tools
governance tools over the testing 3. Evidence of users job
period and inspect the evidence to function and role
determine the appropriate personnel
confirmed the access and the access
based on the job function and role is
appropriate.
Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Change Management Policy
Layer determine that the organization has a and/or observation inclusive of Blockchain
documented Blockchain change policies
approval policy and procedure and 2. If available, Blockchain
inspect it includes key controls, policy
oversight and escalation procedures.
Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Blockchain Governance
Layer determine that the organization has a and/or observation Framework
documented Blockchain governance 2. Evidence of approved
framework. changes
2. Select a sample of approved 3. Job Scheduler
changes and inspect the appropriate
personnel approved the change and it
was tested in accordance with the
Blockchain governance framework.
Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Problem Management
Layer determine that the organization has a and/or observation Process for Blockchain
documented problem management Configurations
process for Blockchain 2. Blockchain Configurations
Configurations. error or exceptions log
2. Select a sample of errors or
exceptions and inspect the evidence
to ensure they were tracked,
escalated, root causes identified and
resolved.
Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Information Security Policy
Layer determine that the organization has a and/or observation of Access
documented recertification policy and Provisioning/Deprovisioning
it is reviewed at least annually and Policy
updated as necessary. 2. Evidence of recertifications
2. Select a sample of recertifications for the Blockchain
for the Blockchain configuration tools configuration tools
over the testing period and inspect the 3. Evidence of users job
evidence to determine the appropriate function and role
personnel confirmed the access and
the access based on the job function
and role is appropriate.
Infrastructure ITGCs 1. Inquire with control owner to Inquiry, Inspection, 1. Change Management
Layer determine if a Change Management and/or observation policies, procedures, and
policy exists and it is updated as standards
needed. 2. Evidence of the last review
2. Inspect the policy to ensure of documented Change
emergency changes to Blockchain Management Process.
configuration is included. 3. Population of emergency
3. Select a sample of emergency changes for the applications
changes to Blockchain configurations and systems
and inspect the evidence to ensure 4. Evidence of emergency
policies were followed and the change and approvals
appropriate personnel approved the
change.
Infrastructure ITGCs 1. Inquire with control owner to Inquiry, Inspection, 1. Blockchain Operations
Layer determine if a Blockchain Operations and/or observation policy and procedures
policy exists and it is updated as 2. Evidence of a Blockchain
needed. change
2. Inspect the evidence of a
Blockchain change to ensure the
policies and procedures have been
updated to include the updated
integration
Infrastructure Business 1. Inquire with the control owner to Inquiry, Inspection, 1. Back out plan
Layer Continuity determine if a formal Blockchain and/or observation 2. Blockchain
and Disaster failure plan exists. failure plan
Recovery 2. Obtain the most recent version of 3. Business Continuity plan
business continuity and disaster
recovery plans and verify a back out
plan is included for Blockchain.
Infrastructure Business 1. Inquire with the control owner to Inquiry, Inspection, 1. Business Continuity and
Layer Continuity determine if a formal business and/or observation Disaster Recovery plan
and Disaster continuity and disaster recovery 2. Evidence of the organization
Recovery management program exists (i.e., conducting tests of outages and
governance, resources, plans) documenting the results.
2. Obtain the most recent version of
business continuity and disaster
recovery plans and verify whether it
has been approved by a Senior
Management executive and includes
the following:
Business continuity objectives
Business processes and critical
information assets in scope
Information security continuity
Business impact analysis
Recovery objectives and priorities,
including Recovery Time Objectives
(RTO) and Recovery Point
Objectives (RPO)
Roles and responsibilities
Dependencies and critical functions
for delivery of critical services
3. Inquire with the control owner to
determine whether the business
continuity and disaster recovery plans
have been communicated and shared
with stakeholders with associated
responsibilities.
4. Inquire with control owner to
determine how often the business
continuity and disaster recovery plans
are tested and how they document the
results of the test.
Infrastructure Business 1. Verify the standard backup and Inquiry, Inspection, 1. Standard backup and
Layer Continuity recovery plan includes a section and/or observation recovery plan
and Disaster regarding Blockchain configuration 2. Agreements for the data
Recovery tools and data. center or cloud if applicable
2. Inspect the agreements with the
data center or cloud providers to
determine whether they exist and
cover the current period.
Infrastructure Business 1. Inquire with control owner and Inquiry, Inspection, 1. Business Continuity and
Layer Continuity inspect evidence to determine and/or observation Disaster Recovery plan
and Disaster whether the risks identified and 2. Evidence of risks identified
Recovery documented have been mitigated
within the business continuity and
disaster recovery plan.
Infrastructure Business 1. Inquire with control owner and Inquiry, Inspection, 1. Business continuity and
Layer Continuity inspect evidence to determine and/or observation disaster recovery plan testing
and Disaster whether the business continuity and report.
Recovery disaster recovery plans are tested on a 2. Evidence that corrective
semi-annually basis, if test results are actions are taken if necessary.
reviewed and corrective actions are
taken if necessary.
Infrastructure Business 1. Inquire with control owner to Inquiry, Inspection, 1. Information Security
Layer Continuity determine whether communication and/or observation policies and procedures
and Disaster occurs to the individuals and teams 2. Business Continuity
Recovery involved in the recovery processes so Management Policy
that key stakeholders understand their 3. Technology Operations
responsibilities in the event of a Disaster Recovery Plan
disaster.
Infrastructure IT Asset 1. Inspect a sample of vendors and Inquiry, Inspection, 1. Vendor contracts
Layer Management validate that the vendor contracts are and/or observation 2. Population of vendors
monitored periodically.
Infrastructure IT Asset 1. Inspect a sample of vendors and Inquiry, Inspection, 1. Vendor licensing
Layer Management validate that the vendor licensing and/or observation agreements
agreements are monitored 2. Population of vendors
periodically and renewed as needed. 3. Log of tracking vendor
licensing agreements
Infrastructure IT Asset 1. Inquire with the control owner and Inquiry, Inspection, 1. Vendor management policy
Layer Management determine if a vendor management and/or observation and procedure
policy exists. 2. Vendor contracts
2. Inspect a sample of agreements and 3. Population of new vendors
validate that the policy and for the testing period
procedures were reviewed and
approved on a periodic basis.
3. Verify each Blockchain vendor
includes the standard contract,
templates and requirements that are
aligned with the vendor selection
Infrastructure IT Asset 1. Inquire with the control owner and Inquiry, Inspection, 1. Vendor management policy
Layer Management determine if all relevant information and/or observation and procedure
security requirements are established 2. Vendor contracts
and agreed with each supplier/vendor 3. Population of new vendors
that may access, process, store, for the testing period
communicate, or provide IT
infrastructure components for, the
organizations information.
2. Inspect a sample of agreements and
validate they include resource
ownership, hardware procurement
requirements, and Blockchain
ownership.
4.4 Architecture Layer Assessment Work Program In some embodiments, blockchain architecture layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain architecture stack/layer supporting blockchain permissioned and/or permissioned networks operations and participant lifecycle management.
The sub-risk categories, control and testing objectives, test procedures and request lists for Architecture Layer risk category are provided below in Tables 11-13.
TABLE 11
Risk Level
Risk Risk (L, M, H)
Risk Category Domain Classification Number Risk Description (As applicable)
Architecture Layer Blockchain Strategic, AL-BP1 Lack of an established baseline for L, M, H
Platform & Operational, Blockchain systems may affect
Protocol Financial, operational environments and
Configuration Compliance, compromise security.
Legal, or
Reputational
Architecture Layer Blockchain Strategic, AL-BP2 If hardening standards have not been L, M, H
Platform & Operational, developed, defined, or implemented.
Protocol Financial, Blockchain systems are unprotected
Configuration Compliance, and vulnerable to malicious attacks.
Legal, or
Reputational
Architecture Layer Blockchain Strategic, AL-BP3 Inadequate processes in the design L, M, H
Platform & Operational, phase of the Blockchain
Protocol Financial, implementation may negatively
Configuration Compliance, impact core system performance.
Legal, or
Reputational
Architecture Layer Blockchain Strategic, AL-BP4 Lack of configuration standards L, M, H
Platform & Operational, and/or lack of adherence to
Protocol Financial, established configuration standards
Configuration Compliance, may lead to failures or inefficiencies
Legal, or in the Blockchain production
Reputational environment.
Architecture Layer Blockchain Strategic, AL-BP5 Lack of configuration standards L, M, H
Platform & Operational, and/or lack of adherence to
Protocol Financial, established configuration standards
Configuration Compliance, may lead to failures or inefficiencies
Legal, or in the Blockchain production
Reputational environment.
Architecture Layer Blockchain Strategic, AL-BP7 Insufficient test plans lead to the L, M, H
Platform & Operational, inability to meet the requirements
Protocol Financial, identified in the analysis and design
Configuration Compliance, phase.
Legal, or
Reputational
Architecture Layer Blockchain Strategic, AL-BP8 Insufficient test plans lead to the L, M, H
Platform & Operational, inability to meet the requirements
Protocol Financial, identified in the analysis and design
Configuration Compliance, phase.
Legal, or
Reputational
Architecture Layer Hardware Security Strategic, AL-BP9 HSM devices are properly L, M, H
Modules Operational, configured and maintained
Financial, which may expose the Blockchain use case
Compliance, supporting systems or sensitive data
Legal, or to unauthorized parties.
Reputational
Architecture Layer Signature Strategic, AL-SM1 Lack of effective cryptographic keys L, M, H
Management Operational, management may expose the keys to
Financial, potential modification, loss,
Compliance, destruction or disclosure to
Legal, or unauthorized parties.
Reputational
Architecture Layer Signature Strategic, AL-SM2 Lack of effective cryptographic keys L, M, H
Management Operational, management may expose the keys to
Financial, potential modification, loss,
Compliance, destruction or disclosure to
Legal, or unauthorized parties.
Reputational
Architecture Layer Signature Strategic, AL-SM3 Lack of effective cryptographic keys L, M, H
Management Operational, management may expose the keys to
Financial, potential modification, loss,
Compliance, destruction or disclosure to
Legal, or unauthorized parties.
Reputational
Architecture Layer Signature Strategic, AL-SM4 Lack of effective cryptographic keys L, M, H
Management Operational, management may expose the keys to
Financial, potential modification, loss,
Compliance, destruction or disclosure to
Legal, or unauthorized parties.
Reputational
Architecture Layer Cryptography Strategic, AL-C1 Inadequate protection of information L, M, H
Operational, in Blockchain systems through
Financial, cryptographic techniques and
Compliance, effective key management may
Legal, or result in the potential compromise of
Reputational confidentiality or integrity of
information in transmission
or storage.
Architecture Layer Cryptography Strategic, AL-C2 Inadequate protection of information L, M, H
Operational, in Blockchain systems through
Financial, cryptographic techniques and
Compliance, effective key management may
Legal, or result in the potential compromise of
Reputational confidentiality or integrity of
information in transmission
or storage.
Architecture Layer Cryptography Strategic, AL-C3 Inadequate protection of information L, M, H
Operational, in Blockchain systems through
Financial, cryptographic techniques and
Compliance, effective key management may
Legal, or result in the potential compromise of
Reputational confidentiality or integrity of
information in transmission
or storage.
Architecture Layer Cryptography Strategic, AL-C4 Inadequate protection of information L, M, H
Operational, in Blockchain systems through
Financial, cryptographic techniques and
Compliance, effective key management may
Legal, or result in the potential compromise of
Reputational confidentiality or integrity of
information in transmission
or storage.
Architecture Layer Cryptography Strategic, AL-C5 Lack of compliance may result in L, M, H
Operational, ineffective controls thereby
Financial, heightening organization′s security
Compliance, and compliance risks.
Legal, or
Reputational
Architecture Layer Scalability /Capacity Strategic, AL-SC1 System capacity is not monitored L, M, H
Management Operational, which may lead to interruption
Financial, and/or failure to key systems.
Compliance,
Legal, or
Reputational
Architecture Layer Scalability/Capacity Strategic, AL-SC2 Inadequate procedures to monitor L, M, H
Management Operational, the capacity and performance of IT
Financial, resources may lead to delivery
Compliance, failure of service performance
Legal, or agreements.
Reputational
Architecture Layer Scalability/Capacity Strategic, AL-SC3 Failure to define, agree, record and L, M, H
Management Operational, manage the levels of service as
Financial, required by the business may result
Compliance, in the agreed service continuity and
Legal, or availability commitment to
Reputational customers not being met in all
circumstances.
Architecture Layer Availability Strategic, AL-A1 Lack of redundant information L, M, H
Operational, processing facilities may lead to
Financial, disruption of critical services in the
Compliance, event Blockchain information
Legal, or processing facilities are unavailable
Reputational due to excess capacity or other
threats.
Architecture Layer Encryption (EN) Strategic, AL-EN01 Privileged access is not L, M, H
Operational, appropriately restricted, logged, and
Financial, monitored for unencrypted data,
Compliance, which can lead to unauthorized
Legal, or access
Reputational
Architecture Layer Encryption (EN) Strategic, AL-EN02 Data in transit is not secure and may L, M, H
Operational, be compromised or accessed by
Financial, unauthorized participants,
Compliance, compromising the integrity of the
Legal, or data
Reputational
Architecture Layer Encryption (EN) Strategic, AL-EN03 Data at rest or in storage is not L, M, H
Operational, secure and may be accessible by
Financial, unauthorized participants,
Compliance, compromising the integrity of the
Legal, or data
Reputational
Architecture Layer Encryption (EN) Strategic, AL-EN04 Databases lack encryption to protect L, M, H
Operational, and recover data in the case of loss
Financial, or theft
Compliance,
Legal, or
Reputational
Architecture Layer Encryption (EN) Strategic, AL-EN05 Data is not retained for DLT inputs. L, M, H
Operational, PKIs, or other critical systems; lack
Financial, of availability limits backup and
Compliance, recovery capability
Legal, or
Reputational
Architecture Layer Encryption (EN) Strategic, AL-EN06 PKI Certificate Authority (CA) is L, M, H
Operational, insufficiently isolated from tire rest
Financial, of the network
Compliance,
Legal, or
Reputational
Architecture Layer Encryption (EN) Strategic, AL-EN07 No PKI Certificate Authority (CA) L, M, H
Operational, is present in the organization′s
Financial, network to validate data
Compliance, transmission or transactions on the
Legal, or blockchain
Reputational
Architecture Layer Key Management Strategic, AL-EN07 Lack of proper physical and logical L, M, H
Operational, custody of the keys (private and
Financial, public) can compromise a single or
Compliance, multiple users on the Blockchain.
Legal, or
Reputational
Architecture Layer Data Retention Strategic, AL-DR01 Data is not retained for DLT inputs, L, M, H
(DR) Operational, PKIs, or other critical systems; lack
Financial, of availability limits backup and
Compliance, recovery capability
Legal, or
Reputational
Architecture Layer Consensus (CS) Strategic, TL-CS01 No formal consensus protocol is L, M, H
Operational, established, system validators for
Financial, DLT entries lacks authentication
Compliance,
Legal, or
Reputational
Architecture Layer Consensus (CS) Strategic, AL-CS02 Implementation processes for L, M, H
Operational, system coding related to consensus
Financial, have not been defined: no formal
Compliance, channel for change management
Legal, or exists
Reputational
Architecture Layer Consensus (CS) Strategic, AL-CS03 System development and L, M, H
Operational, management life cycle does not
Financial, exist or does not apply to
Compliance, consensus system architecture
Legal, or
Reputational
Architecture Layer Consensus (CS) Strategic, AL-CS04 The organization has no approvals L, M, H
Operational, process for change management
Financial, affecting consensus or docs not
Compliance, secure against improper approvals
Legal, or being issued
Reputational
Architecture Layer Consensus (CS) Strategic, AL-CS05 There is no access review or audit L, M, H
Operational, mechanism for the consensus
Financial, protocol or any users, systems, or
Compliance, participants affiliated with DLT
Legal, or validation
Reputational
Architecture Layer Consensus (CS) Strategic, AL-BC1 Consensus mechanisms L, M, H
Operational, implemented do not provide comfort
Financial, on the immutability of the data
Compliance, stored on the Blockchain.
Legal, or
Reputational
Architecture Layer Consensus (CS) Strategic, AL-BC2 Consensus mechanisms L, M, H
Operational, implemented do not provide comfort
Financial, on the immutability of the data
Compliance, stored on the Blockchain.
Legal, or
Reputational
TABLE 12
In-scope/Out-
Risk of-Scope (TBD-
Category Domain Control/Test Objective Control Description As per engagement)
Architecture Blockchain Platform & The organization has created A configuration management In-scope
Layer Protocol Configuration a configuration management program and database exists to
database (CMDB) that implement, maintain and control
houses all Blockchain configuration of Blockchain
systems and infrastructure. systems and oilier infrastructure
A baseline configuration of elements (including hardware,
the Blockchain system is software, firmware, and
created, implemented, and documentation). The program
maintained. requires the identification of
baseline configurations (original
versions) of Blockchain
infrastructure elements (hardware,
software etc.). A central repository
of configuration items (Cl), their
attributes, and their inter-linkages
is established and maintained. CIs
are linked to the services that they
support. Current and prior
configuration for all CIs, including
Blockchain production servers,
network devices, and databases is
captured and maintained in the
central repositon. in order to
support rollback
Architecture Blockchain Platform & Blockchain systems Blockchain system configuration In-scope
Layer Protocol Configuration hardening standards arc and hardening standards arc
established and maintained. developed, communicated,
Blockchain system implemented and maintained. The
configuration and hardening standards followed address all
standards are consistent known security vulnerabilities and
with industry-accepted are consistent with industry-
standards, vendor specific accepted system hardening
guidelines and address all standards and any vendor specific
known security guidelines
vulnerabilities
Architecture Blockchain Platform & The Blockchain Instance The Blockchain Instance process In-scope
Layer Protocol Configuration impact on core processing impact on core system
system performance has performance is documented and
been determined and approved by IT and the
appropriately addressed as Blockchain Instance program
part of functional management.
specification process
Architecture Blockchain Platform & Newly implemented the Once the Blockchain Instance has In-scope
Layer Protocol Configuration Blockchain Instances are been configured, a test plan is
configured to completely or developed to ensure meeting all
accurately process data. functional requirements and
The Blockchain Instances approved by the Blockchain
are configured to effectively Instance program management.
meet the business The Blockchain Instance
requirements. configurations are tested by the
impacted/required business and/or
the Blockchain Instance program
management team. Test
exceptions are appropriately
recorded, monitored and tracked
for resolution prior to migration to
production.
Architecture Blockchain Platform & Auditability of the The audit logging of the In-scope
Layer Protocol Configuration Blockchain Instance Blockchain Instance software tool
processing has been enabled has been enabled. The ability to
within the tool. change the audit capacities is
restricted to authorized personnel
outside of the configuration
function.
Architecture Blockchain Platform & Testing architecture and Once the Blockchain Instance has In-scope
Layer Protocol Configuration requirements have been been configured, a test plan is
defined and documented. developed to ensure meeting all
Test plan including test functional requirements and
cases and procedures are approved by the Blockchain
formally defined. Instance program management.
The Blockchain Instance
configurations are tested by the
impacted/required business and/or
the Blockchain Instance program
management team. Test
exceptions are appropriately
recorded, monitored and tracked
for resolution prior to migration to
production.
Architecture Blockchain Platform & Technical test environments The Blockchain Instance In-scope
Layer Protocol Configuration are stable and managed configuration testing take place in
properly. environments which are logically
segregated from and mirror the
legacy system production
environment.
Architecture Hardware Security HSM devices are properly HSM devices are deployed, In-scope
Layer modules configured and maintained properly configured and
which may expose the maintained to prevent the
Blockchain use case Blockchain use case supporting
supporting systems or systems or sensitive data exposure
sensitive data to to unauthorized parties
unauthorized parties
Architecture Signature Management The integrity of the A formal key management system In-scope
Layer Blockchain cryptosystem is and associated processes exist to
maintained through the securely manage (i.e.. generate,
proper management of distribute, store, access, backup
encryption keys. Public and and destroy) secret/private keys
private keys are securely and public keys issued by trusted
managed through formal Certification Authorities. Formal
management processes. procedures are in place to protect
keys used to secure stored
cardholder data against disclosure
and misuse. Public key certificates
are issued per defined standards or
from an approved service
provider.
Architecture Signature Management The integrity of the 1. Examine user access lists to In-scope
Layer Blockchain cryptosystem is verify that access to keys is
maintained through the restricted to the fewest number of
proper management of custodians necessary
encryption keys. 2. Verify whether equipment used
Cryptographic key access to generate, store, and archive
and storage is restricted and keys are protected.
controlled.
Architecture Signature Management The integrity of the Cryptographic keys are stored in In-scope
Layer Blockchain cryptosystem is the fewest locations possible.
maintained through the Secret mid private keys used to
proper management of encrypt/decrypt cardholder data
encryption keys. are stored in one (or more) of the
Cryptographic keys arc following forms at all times:
securely stored. Encrypted with a key-encrypting
The integrity of the key that is at least as strong as the
Blockchain cryptosystem is data-encrypting key, and that is
maintained through the stored separately from the data-
proper management of encrypting key
encryption keys. Within a secure cryptographic
device (such as a hardware (host)
security module (HSM) or PTS-
approved point-of-interaction
device)
As at least two full-length key
components or key shares, in
accordance with an industry-
accepted method
Architecture Signature Management The integrity of the Cryptographic keys are changed at In-scope
Layer Blockchain cryptosystem is the end of their cryptoperiod. as
maintained through the defined by the associated
proper management of application vendor or key owner,
encryption keys. and based on industry best
Cryptographic key change practices and guidelines. Keys arc
management is followed in retired or replaced (for example,
accordance with best archiving, destruction, and/or
practices and guidelines. revocation) as deemed necessary
when the integrity of the key has
been weakened (for example,
departure of an employee with
knowledge of a clear-text key
component), or keys are suspected
of being compromised.
Architecture Cryptography Control: Stored classified Classified data (e.g.. CUI, PHI. In-scope
Layer data are encrypted and CHD. PII) is stored in an
access controlled. encrypted format regardless of the
Control Objective: Data-at- medium (including mobile
rest is protected through devices). Access to the encryption
cryptographic techniques. keys is restricted to authorized
personnel.
Architecture Cryptography Data-at-rest is protected Logical access for disk encryption In-scope
Layer through cryptographic is managed separately and
techniques. Disk encryption independently of native operating
managed independently of system authentication.
the native operating system
authentication.
Architecture Cryptography Data-in-transit is protected Cryptographic techniques are used In-scope
Layer through cryptographic to protect the confidentiality and
techniques. Data integrity in integrity of data in transmission.
transmission protected with While transmitting cardholder
secure cryptography. data, the following measures are
implemented:
Only trusted keys and certificates
are accepted.
The protocol in use only supports
secure versions or configurations.
The encryption strength is
appropriate for the encryption
methodology in use.
Architecture Cryptography Data-in-transit is protected Secure messaging utilities and In-scope
Layer through cryptographic facilities are used to protect data in
techniques. Data is transmission. Electronic
protected in transmission messaging such as MQ Series,
through secure messaging middleware, system to system
utilities and facilities. application calls, batch processing,
email. Electronic Data Interchange
(EDI), and instant messaging, has
security provisions in place to
protect messages from
unauthorized access, modification,
and denial of service.
Architecture Cryptography Cryptographic controls Cryptographic controls are used in In-scope
Layer comply with relevant compliance with all relevant
agreements, legislation, and agreements, legislation, and
regulations. Cryptographic regulations. FIPS-validated
controls have been cryptography is leveraged to
established to comply with protect the confidentiality of CUI.
all business relevant If cryptography is required based
agreements, legislation, and on the selection of other security
regulations. controls, each type of
cryptography required is clearly
defined.
Architecture Cryptography System capacity is Real time monitoring of system In-scope
Layer monitored in real time to capacity is performed to enable the
meet availability implementation of additional
requirements. System capacity to help meet availability
capacity is monitored for commitments and requirements,
operations regarding and reports are made available for
information processing management review.
facilities
Architecture Scalabiltiy/Capacity Adequate capacity is Availability requirements are In-scope
Layer Management maintained to prevent agreed upon with customers.
interruptions. System Availability, capacity, and
capacity is adequately performance baselines have been
monitored to ensure system established based on customer
availability is maintained. needs, business impact analysis,
organizational policies etc.
Adequate capacity, performance,
and availability is maintained to
prevent business disruptions, and
to meet existing and changing
business needs.
Architecture Scalabiltiy/Capacity Baselines are monitored for Deviations from established In-scope
Layer Management deviations and are resolved availability, performance, and
or followed up. Maintain capacity baselines are monitored,
service availability, efficient reported, and resolved. After
management of resources, monitoring, measuring, analyzing,
and optimization of system reporting, and reviewing
performance through availability, performance, and
prediction of future capacity deviations from
performance and capacity established baselines, all
requirements. outstanding issues are followed
up.
Architecture Availability Blockchain production Blockchain production systems In-scope
Layer system availability is are monitored for availability and
monitored and incidents are any incidents are documented in a
documented. Technical ticketing system.
capabilities exist to enable
resiliency of Blockchain
information processing
facilities in accordance with
availability objectives in the
event of disruption.
TABLE 13
Test Type
Risk (TBD-As per
Category Domain Test Procedure (#) engagement) Request List (#)
Architecture Blockchain 1. Inquire with the control owner to Inquiry, 1. Policies, procedures,
Layer Platform & determine whether a configuration Inspection, and/or related to the Blockchain
Protocol management database (CMDB) that observation baseline configuration
Configuration includes Blockchain configuration settings on production
items (Cl) is maintained. infrastructures.
2. Verify whether a configuration 2. Enterprise Blockchain
management plan is documented and production infrastructure
maintained and includes the following: configuration management
Roles and responsibilities plan.
Process for identifying and managing
CIs
Definitions of CI
Interlinkages between CIs
3. Inspect the CMBD and determine for
a sample of systems, where the
Blockchain baseline configuration is
maintained. Also, validate whether
previous versions of the CIs and
corresponding documentation is
archived and maintained to support
rollback.
4. Verify whether the CMDB is
reviewed for accuracy and consistency
on a periodic basis. Verify whether the
organization reviews and updates the
baseline configuration of the
Blockchain system on a periodic basis
or upon any upgrades or installations.
Architecture Blockchain 1. Inquire with control owner to Inquiry, 1. Provide evidence of the
Layer Platform & determine if the organization: Inspection, and/or organization′s documented
Protocol Establishes and documents observation change management
Configuration configuration settings for Blockchain methodology for the
technology products employed within production environment.
the information system using the 2. Provide evidence of
appropriate security configuration Blockchain Network
baseline that reflect the most restrictive Hardening Guidelines.
mode consistent with operational Production Network
requirements: Security Standard, and
Implements the configuration settings; Change Management
2. Inquire of the control owner and methodology.
determine the Blockchain system 3. Change Management
configuration standards are consistent methodology
with industry-accepted configuration 4. Production Network
and hardening standards and are applied Security Standard.
when new systems are configured and 5. Blockchain
verified as being in place before a Infrastructure Hardening
Blockchain system is installed on the Guidelines.
network.
3. Inspect the Network Hardening
Guidelines. Production Network
Security Standard, and Change
Management methodology and
determine if the organization has
documented and implemented a change
management methodology for the
production environment to govern the
Blockchain configuration management
process.
Architecture Blockchain 1. Inquire with control owner to Inquiry, 1. SDLC policies and
Layer Platform & whether an established system Inspection, and/or procedures.
Protocol development lifecycle process is in observation 2. Evidence that an
Configuration place, documented, maintained, and established system
applied for all Blockchain system and development lifecycle
software design, acquisition, process is in place,
implementation, configuration, documented, maintained
integration, testing, modification, and for the development or
maintenance. installation of Blockchain
2. Obtain and inspect SDLC policies systems.
and procedures to determine whether mi 3. Performance
established Blockchain system requirements for
development lifecycle process is Blockchain information
documented. systems and information
3. Verify whether an impact assessment services are identified.
and performance requirements for
Blockchain information systems and
information services are identified as
part of SDLC efforts, business process
re-design, etc.
Architecture Blockchain 1. Obtain Blockchain systems Inquiry, 1. Obtain Blockchain
Layer Platform & configurations. Inspection, and/or systems configurations.
Protocol 2. Assess configuration relative to observation
Configuration functional requirements.
Architecture Blockchain 1. Obtain Blockchain systems Inquiry, 1. Obtain Blockchain
Layer Platform & configurations. Inspection, and/or systems configurations.
Protocol 2. Assess Audit logging capabilities in observation
Configuration the Blockchain system relative to
internal guidelines and leading
practices.
Architecture Blockchain 1. Obtain Blockchain systems test plans Inquiry, 1. Obtain Blockchain
Layer Platform & and requirements. Inspection, and/or systems executed test plans
Protocol 2. Determine if the test plans are observation and requirements.
Configuration executed as per requirements.
Architecture Blockchain 1. Obtain information including version Inquiry, 1. Obtain information
Layer Platform & numbers of the test and production Inspection, and/or including version numbers
Protocol environments for Blockchain systems. observation of the test and production
Configuration 2. Determine if the testing takes place in environments for
environments which are logically Blockchain systems.
segregated from and mirror the legacy
system production environment.
Architecture Hardware Security Determine if HSM device(s) are Inquiry, 1. Obtain HSM information
Layer Modules deployed, properly configured and Inspection, and/or including vendor,
maintained to prevent the Blockchain observation configuration and leading
use case supporting systems or sensitive practices guidelines.
data exposure to unauthorized parties.
Architecture Signature 1. Review key management procedures Inquiry, 1. Encryption and Key
Layer Management and determine if they address secure Inspection, and/or Management policies and
generation, distribution, storage, observation procedures.
backup, and access management of 2. User access list of
keys. cryptographic key
2. Review key management standards to custodians.
determine key strength aligns with 3. Information Security
industry leading standards. policies and procedures
3. Determine through interview with 4. Security Incident
control owner that formal roles and Response Process
responsibilities have been established 5. Audit and
for management keys. accountability policies.
4. Examine key-management policies 6. Procedures addressing
and procedures to verify processes arc non-repudiation.
specified to protect keys against 7. Automated mechanisms
disclosure and misuse and include at configured with non-
least the following: repudiation capabilities.
Access to keys is restricted to the
fewest number of custodians necessary.
Key-encrypting keys are at least as
strong as the data encrypting keys they
protect.
Key-encrypting keys are stored
separately from data encrypting keys.
Keys are stored securely in the fewest
possible locations and forms.
5. Verify that key-management
procedures specify how to generate
strong keys.
6. Observe the method for generating
keys to verify that strong keys are
generated.
7. Observe the method for distributing
keys to verify that keys are distributed
securely.
8. Observe the method for storing keys
to verify that keys are stored securely.
Architecture Signature 1. Inquire about Key Management Inquiry, 1. Obtain Key Management
Layer Management process. Inspection, and/or policies and procedure
2. Review the key Management process observation 2. Test approval, SOD and
and determine if appropriate level of ownership activities for
approval, SOD, and ownership Key Management
mechanisms are in place.
3. Test approval. SOD. and ownership
mechanisms to determine if the Key
Management process is safe, secure and
docs not lack required level of integrity.
Architecture Signature 1. Examine key storage locations and Inquiry, 1. Identify and assess key
Layer Management observe processes to verify that keys are Inspection, and/or storage locations,
stored in the fewest possible locations. observation documented procedures,
2. Examine documented procedures to system configurations.
verify that cryptographic keys used to
encrypt/decrypt cardholder data must
only exist in one (or more) of the
following forms at all times.
Encrypted with a key-encrypting key
that is at least as strong as the data-
encrypting key, and that is stored
separately from the data-encrypting key
Within a secure cryptographic device
(such as a hardware (host) security
module (HSM) or PTS-approved point-
of-interaction device)
As key components or key shares, in
accordance with an industry-accepted
method
3. Examine system configurations and
key storage locations to verify that
cryptographic keys used to
encrypt/decrypt cardholder data exist in
one (or more) of the following form at
all times.
Encrypted with a key-encrypting key
Within a secure cryptographic device
(such as a hardware (host) security
module (HSM) or PTS-approved point-
of-interaction device)
As key components or key shares, in
accordance with an industry-accepted
method
4. Wherever key-encrypting keys are
used, examine system configurations
and key storage locations to verify:
Key-encrypting keys are at least as
strong as the data-encrypting keys they
protect
Key-encrypting keys are stored
separately from data-encrypting keys.
Architecture Signature 1. Verify that key-management Inquiry, 1. Identify and assess
Layer Management procedures include a defined crypto Inspection, and/or encryption mechanism for
period for each key type in use and observation Key Management
define a process for key changes at the
end of the defined cryptoperiod (s) (
(for example, after a defined period of
time has passed and/or after a certain
amount of cipher-text has been
produced by a given key)
2. Interview personnel to verify that
keys are changed at the end of the
defined cryptoperiod(s).
3. Verify that key-management
procedures specify processes for the
following:
The retirement or replacement of keys
when tire integrity of the key has been
weakened
The replacement of known or
suspected compromised keys.
Any keys retained after retiring or
replacing are not used for encryption
operations
4. Interview personnel to verify the
following processes are implemented:
Keys are retired or replaced as
necessary when the integrity of the key
has been weakened, including when
someone with knowledge of the key
leaves the company.
Keys are replaced if known or
suspected to be compromised.
Any keys retained after retiring or
replacing are not used for encryption
operations.
Architecture Cryptography 1. Inquire with the control owner to Inquiry, 1. Information Security
Layer determine how classified data is Inspection, and/or Policies.
encrypted at rest in all formats observation 2. Data Classification
(databases, media, mobile devices, Policy
removable storage, etc.) and how access 3. Information Security
to the encryption keys is restricted to Policy for encryption
authorized personnel in accordance with requirements.
encryption requirements. For data at 4. System generated list of
rest, assess whether one of the individuals with access to
following is implemented: the encryption keys with
Full disk encryption: names and respective job
Partial encryption where the access title.
control will only allow writing to the 5. Configuration or
encrypted partition. evidence showing systems
2. Obtain and inspect the cryptographic components/backups are
controls policy to determine whether it encrypted using AES-256
aligns to industry standards. via FIPS 140-2 validated
3. Obtain a system generated list of encryption
individuals with access to the 6. Evidence indicating the
encryption keys and determine whether use of either full disk
access is restricted to the authorized encryption, or partial
personnel. encryption with access
4. Inspect that only approved hard drive controls to allow writing to
encryption software has been deployed the encrypted partition
to mobile devices and systems that hold
sensitive data.
Architecture Cryptography 1. Inquire with the control owner to Inquiry, 1. Provide the policies and
Layer determine if disk encryption is used Inspection, and/or procedures related to
(rather than file or column-level observation access management.
database encryption). 2. Provide the
2. Inspect policies and procedures and configurations for the in
the configurations for the in scope scope systems validating
systems to ensure that logical access is that logical access is
managed separately and independently managed separately and
of native operating system independently of native
authentication and access control operating system
mechanisms (for example, by not using authentication and access
local user account databases or general control mechanisms.
network login credentials). 3. Evidence that decryption
3. Validate that decryption keys are not keys are not associated
associated with user accounts. with user accounts.
Architecture Cryptography 1. Inquire with control owners to Inquiry, 1. Information Security
Layer determine that sensitive data is Inspection, and/or Policies and procedures
encrypted while being exchanged observation related to Encryption.
between systems within the network 2. Screenshots of the
and also when transmitted over public applicable encryption or
networks. network protection utility.
2. Identify all locations where sensitive 3. TLS implementation
data is transmitted or received over system configurations.
open, public networks. Examine 4. Security
documented standards and compare to Implementation Guide.
system configurations to verify the use
of security protocols and strong
cryptography for all locations.
3. Select and observe a sample of
inbound and outbound transmissions as
they occur (for example, by observing
system processes or network traffic) to
verify that all sensitive data is encrypted
with strong cryptography during transit.
Architecture Cryptography 1. Inspect if the organization ensures Inquiry, 1. Evidence that secure
Layer that the transmission, movement, and Inspection, and/or messaging utilities and
removal of information is restricted to observation facilities are used to protect
authorized users and processes, and is data in transmission.
protected. Thus enabling the entity to 2. Policies and procedures
meet its commitments and requirements related to the protection of
as they relate to security. availability, data-in-transit.
processing integrity, or confidentiality
or any combination thereof.
2. For the electronic messaging systems,
provide screenshots and/or
documentation that controls have been
implemented to address the following :
protecting messages from unauthorized
access, modification or denial of
service, ensuring correct addressing and
transportation of the message, general
reliability and availability of the
service, legal considerations, obtaining
approval prior to using external public
services such as instant messaging or
file sharing, stronger levels of
authentication controlling access from
publicly accessible networks.
Architecture Cryptography 1. Inquire with control owner to Inquiry, 1. Relevant agreements and
Layer determine whether cryptographic Inspection, and/or guidance for applicable
controls are used in compliance with observation legislation and regulations
relevant agreements, legislation, and 2. Policies and procedures
regulations. related to encryption and
2. Obtain and inspect the Encryption, key management.
and Cryptographic Controls. Encryption
and Key Management security policies
and procedures to determine that each
type of cryptography is defined.
Determine whether the policies outline
the following:
Tenant-specific encryption;
Security requirements on
cryptographic keys;
Use of standardized cryptographic
methods;
Use of cryptographic keys.
Architecture Scalability/Capacity 1. Inquire with the control owner and Inquiry, 1. Provide Capacity
Layer Management determine if real time monitoring of Inspection, and/or Planning report
system capacity is performed and the observation 2. Provide screenshots of
dashboard report is available for monitoring dashboards
management review. 3. ISMS Statement of
2. Inspect the capacity monitoring tools Applicability
for a sample of production and sandbox
instances and determine if they arc
monitored in real time for. among
others. CPU, API request time, web
request time, transaction processing
time, and report request times.
3. Inspect if monitoring dashboards are
available for management review, for
individual instances and in aggregate, to
enable real-time monitoring and future
capacity planning
Architecture Scalability/Capacity 1. Verify that there is a formally Inquiry, 1. Audit and accountability
Layer Management documented capacity plan associated Inspection, and/or policies and procedures
with critical systems and infrastructure. observation addressing audit storage
2. Inquire with the control owner to capacity
determine whether business continuity 2. Evidence showing
objectives are considered while storage capacity.
developing capacity plans.
3. Review the capacity plan and validate
that:
Required capacity is provided, taking
into account aspects such as normal
workloads, contingencies, storage
requirements and IT resource life
cycles;
Provisions such as prioritizing tasks,
fault-tolerance mechanisms and
resource allocation practices are in
place:
Business criticality of systems are
taken into account while determining
capacity:
Projections of future capacity
requirements take into account business
strategy and plans.
Architecture Scalability/Capacity 1. Examine security policies and Inquiry, 1. Security policies and
Layer Management procedures to validate a process to Inspection, and/or procedures detailing
follow up on availability, performance, observation process of remediating
and capacity baselines exists capacity deviations
2. Examine sample of deviations from 2. Record of capacity
availability, performance, and capacity deviations and subsequent
baselines and records which indicate remediation actions taken
appropriate actions were taken to 3. Executive/Board
address outstanding issues. reporting on handled
3. Determine through inquiry and capacity management
inspection of reporting how follow up incidents.
activities to deviations are tracked,
measured, and reported to executives or
the Board of Directors.
Architecture Availability For in-scope Blockchain production Inquiry, 1. System generated list of
Layer systems: Inspection, and/or incident tickets for the
1. Inquire with the control owner and observation period under review (to be
determine whether production systems specified) with screenshot
are monitored for availability and of parameters used to
capacity, and any incidents arc generate the listing.
documented in a ticketing system. 2. Incident tickets for
2. Obtain a population of incident selected sample.
tickets, select a sample, and inspect the 3. Incident dashboard for
ticket details for the selected sample of population of performance
organization services incident tickets incidents tickets for the
from the workflow ticketing system and period under review (to be
determine whether the incident specified).
determine the incidents were assigned 4. Tickets for the samples
an impacted environment, impacted of high severity
account, subject and description, performance incidents
incident type, severity rating, and
customer impacted and were resolved or
are being actively worked to resolution.
3. Inspect the configurations within the
monitoring tool for a sample of
production servers, selected from the
inventory management system, and
determine whether the servers were
configured to be monitored for
availability and capacity and notify
personnel in the event an issue was
identified.
4. Obtain a population of incident
tickets, select a sample of high severity
performance incident tickets, and
inspect the sample of incident tickets to
determine the incidents were assigned
an impacted environment, impacted
account, subject and description,
incident type, severity rating, and
customer impacted and were resolved or
are being actively worked to resolution.
In some embodiments, blockchain architecture layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain architecture stack/layer supporting blockchain permissioned and/or permissioned networks operations and participant lifecycle management.
The sub-risk categories, control and testing objectives, test procedures and request lists for Operational Layer risk category are provided below in Tables 14-16.
TABLE 14
Risk Level
Risk Risk Risk (L, M, H)
Category Domain Classification Number Risk Description (As applicable)
Operational Layer Permissioned Strategic, OL-PN1 As the Blockchain is L, M, H
Network Operational, implemented, the nature of the
Management Financial, instance (permissioned/non
Compliance, permissioned. use case etc.) is not
Legal, or aligned with and the governance
Reputational practices put in place.
Operational Layer Participant Strategic, OL-PO1 User access controls are not L, M, H
Onboarding Operational, enforced, allowing unauthorized
and Off- Financial, individuals to have access to
boarding Compliance, systems and SOA services.
Legal, or
Reputational
Operational Layer Application Strategic, OL-AL1 The Blockchain technology′s L, M, H
Layer Operational, impact on the controls attestations
Financial, (SOC 1/SOC 2 reports) or the
Compliance, Financial Statemcnt/SOX audit
Legal, or scope is not assessed and therefore
Reputational the potential impact is unknown
and not managed.
Operational Layer Application Strategic, OL-AL2 Risk and audit plans are not L, M, H
Layer Operational, updated and therefore do not
Financial, reflect and address the risks
Compliance, associated with the Blockchain
Legal, or technology.
Reputational
Operational Layer Blockchain Strategic, OL-BC1 Consensus mechanisms L, M, H
Concensus Operational, implemented do not provide
Program Financial, comfort on the immutability of the
Management Compliance, data stored on the Blockchain.
Legal, or
Reputational
Operational Layer Blockchain Strategic, OL-BC2 Consensus mechanisms L, M, H
Concensus Operational, implemented do not provide
Program Financial, comfort on the immutability of the
Management Compliance, data stored on the Blockchain.
Legal, or
Reputational
Operational Layer Integration Strategic, OL-IW1 The setup of the Blockchain L, M, H
with off- Operational, software lacks consideration of
Blockchain Financial, new security requirements to
Systems and Compliance, maintain confidentiality, integrity,
Processes Legal, or and availability.
Reputational
Operational Layer Integration Strategic, OL-IW2 Hardware (including L, M, H
with off- Operational, configurations, locations,
Blockchain Financial, capacity/capacity utilization, and
Systems and Compliance, age and data requirements)
Processes Legal, or impacted by the Blockchain
Reputational integration have not been
collected and evaluated,
potentially causing an unknown
impact.
Operational Layer Integration Strategic, OL-IW3 Applications, software and L, M, H
with off- Operational, software components impacted by
Blockchain Financial, the Blockchain software
Systems and Compliance, integration have not been
Processes Legal, or identified and evaluated.
Reputational
Operational Layer Integration Strategic, OL-IW4 User access and segregation of L, M, H
with off- Operational, duties controls are not enforced,
Blockchain Financial, allowing unauthorized users to
Systems and Compliance, migrate Blockchain process
Processes Legal, or configurations into production.
Reputational
Operational Layer Integration Strategic, OL-IW5 System development or L, M, H
with off- Operational, maintenance on a system with
Blockchain Financial, Blockchain dependencies are not
Systems and Compliance, identified and evaluated,
Processes Legal, or potentially causing an unknown
Reputational impact.
Operational Layer Integration Strategic, OL-IW6 The legacy system Software L, M, H
with off- Operational, Development Lifecycle
Blockchain Financial, methodology for change
Systems and Compliance, management processes docs not
Processes Legal, or reflect the integration with the
Reputational Blockchain program management.
Operational Layer Integration Strategic, OL-IW7 Business process changes with L, M, H
with off- Operational, Blockchain dependencies are not
Blockchain Financial, identified and evaluated,
Systems and Compliance, potentially causing an unknown
Processes Legal, or impact.
Reputational
Operational Layer Smart Strategic, OL-SC2 Blockchain data is stored on off- L, M, H
Contracts Operational, chain databases that are unsecure
Financial,
Compliance,
Legal, or
Reputational
Operational Layer Smart Strategic, OL-SC3 The organization lacks a complete L, M, H
Contracts Operational, governance structure to provide
Financial, oversight and security for hard
Compliance, forks in the blockchain
Legal, or architecture
Reputational
TABLE 15
In-scope/Out-of-
scope (TBD-As
Risk Category Domain Control/Test Objective Control Description per engagement)
Operational Permissioned As the Blockchain is implemented, A Blockchain steering In-scope
Layer Network there is alignment with the nature of committee, which includes
Management the instance (permissioned/non executive leadership and senior
permissioned. use case etc.) and the members of the business, risk,
governance practices put in place. compliance and the Blockchain
An appropriate governance regime is program management, meets on
designed and agreed, if required a quarterly basis to conduct
across all participants in the network. business performance reviews of
how the Blockchain aligns with
IT Governance.
Operational Participant All access is logged and monitored All access is logged and In-scope
Layer Onboarding and SOA services maintain the monitored.
and Off- appropriate restricted access. SOA services are restricted from
boarding being accessed by anyone other
than whitelisted
processes/clients.
Operational Application Management has engaged appropriate The Blockchain Program In-scope
Layer Layer members of internal and external audit management meets with external
to assess if the Blockchain technology SOC 1/Financial Statement audit
will have an impact on the controls teams to review the status of the
attestations (SOC 1/SOC 2 reports) or project plan and future the
the Financial Statement/SOX audit Blockchain process
scope. considerations and
management′s assessment on
impact of the Blockchain
technology to the audit scope.
Operational Application Internal audit has been properly The Blockchain management In-scope
Layer Layer engaged and the Blockchain program team meets regularly with
is being considered in the internal members of risk and internal
audit scoping exercises. audit in each business unit
leveraging the Blockchain
technology to ensure the risk and
audit plans are evolving to
address the Blockchain risks.
Operational Blockchain As Blockchain programs are designed Blockchain consensus In-scope
Layer Consensus and implemented, appropriate mechanisms that assure
Program consensus mechanisms are agreed immutability are designed
Management upon, implemented and controlled to implemented and the associated
provide comfort on the immutability controls are documented and
of the data stored on the Blockchain. approved by the business and the
Appropriate controls are designed and Blockchain program
implemented to safeguard the management. Blocks are created
immutability of data captured on the for transactions validated
blockchain. through blockchain consensus
mechanism and cannot be
modified once written.
Operational Blockchain Conesus mechanism automatically Economic trade terms arc In-scope
Layer Consensus determines whether the trade details validated through blockchain
Program match between counterparties or not. consensus mechanism and
Management Automatic validation will not take automatically recorded on the
place if consensus is not reached. blockchain network in a timely
manner.
Operational Integration The Blockchain software is aligned The Blockchain software for
Layer with off- with new security requirements to initial integration into the firm′s
Blockchain maintain confidentiality, integrity, and environment follows a well-
Systems and availability. defined integration plan and is
Processes monitored by the Blockchain
program management.
Operational Integration Hardware impacted by the Blockchain Impact of software integration In-scope
Layer with off- integration is documented and on the firm′s existing hardware
Blockchain evaluated, and results are escalated to configurations, software and
Systems and the Blockchain steering committee. applications is documented and
Processes evaluated. The results of this
evaluation are reported to the
Blockchain steering committee.
Operational Integration Applications and software impacted Impact of software integration In-scope
Layer with off- by the Blockchain integration is on the firm′s existing hardware
Blockchain documented and evaluated, and results configurations, software and
Systems and are escalated to the Blockchain applications is documented and
Processes steering committee. evaluated. The results of this
evaluation are reported to the
Blockchain steering committee.
Operational Integration Operations policies and procedures Access to migrate the In-scope
Layer with off- have been updated to include Blockchain process
Blockchain integration with the Blockchain prior configurations into production is
Systems and to the Blockchain change being placed restricted to personnel who are
Processes into production. independent of the configuration
team. Access to migrate the
Blockchain process
configurations into production is
periodically reviewed to ensure
access is restricted to personnel.
Operational Integration Impact of legacy system development Business Unit IT management In-scope
Layer with off- and maintenance on the Blockchain notifies the Blockchain program
Blockchain configuration is considered during management if system
Systems and legacy System Development Lifecycle development or maintenance on
Processes for legacy systems. a system has been identified as
Impacts to interfaces between legacy having the Blockchain
systems have been identified., e.g. dependencies. The Blockchain
data flow architecture program management evaluates
the impact the legacy system
change will have on the
Blockchain. Details of the
evaluation are documented. If
the Blockchain process is
impacted, the Blockchain is
removed from production and a
back out plan is enabled while a
configuration change order is
processed.
Operational Integration An inventory, including functional The legacy system Software In-scope
Layer with off- use. of all key interfaces and legacy Development Lifecycle
Blockchain systems utilized by the Blockchain is methodology for change
Systems and maintained. management processes has been
Processes Impacts to interfaces between legacy updated to include integration
systems have been identified., e.g. with the Blockchain program
data flow architecture management prior to making
changes to the Blockchain
impacted systems or interfaces.
Operational Integration The Blockchain is reconfigured when Business Unit Operations In-scope
Layer with off- changes in business processes affect management notifies the
Blockchain the Blockchain. Management Blockchain program
Systems and considers both the downstream and management if a business
Processes upstream impact of changes to process change has been
business processes and the use of the identified as having the
Blockchain technology. Blockchain dependencies. The
Blockchain program
management evaluates the
impact the business process
change will have on the
Blockchain configuration.
Details of the evaluation are
documented. If a Blockchain
process is impacted, the
Blockchain is removed from
production and back out plan is
enabled while a configuration
change order is processed.
TABLE 16
Test Type
(TBD—
Risk As per
Category Domain Test Procedure (#) engagement) Request List (#)
Operational Permissioned 1. Inquire with management about the process of Inquiry, 1. Listing of the
Layer Network ensuring alignment with the nature of the instance Inspection, individuals on the
Management and the government practices put in place. and/or Blockchain steering
2. Obtain relevant documentation evidencing the observation committee
consideration of the alignment. 2. Evidence for the
3. Obtain a listing of the individuals on the most recent quarterly
Blockchain steering committee. meeting (meeting
4. Obtain evidence for the most recent quarterly minutes/meeting
meeting (meeting minutes/meeting invites) to invites/emails)
verify that meeting took place and included showing the meeting
members of the Blockchain steering committee. took place
5. Through inspection of the results of business 3. Documentation/
performance review, verify an appropriate review results of the
was performed of how the Blockchain aligns with quarterly business
IT Governance. performance review
of how the Block-
chain aligns with
IT Governance
4. Documentation
leveraged when
considering the
alignment
Operational Participant 1. Inquire with management about the process Inquiry, 1. Listing of users with
Layer Onboarding and frequency in which access is logged and Inspection, access to the SOA
and Off- monitored. and/or services
boarding 2. Obtain a listing of users with access to the observation 2. Documentation
SOA services. showing all access is
3. Obtain documentation showing that all access logged and monitored
is logged and monitored and through inspection, 3. Screenshot showing
verify that only users with permissioned access how access is logged
appear on the listing. and monitored
Operational Application 1. Obtain evidence for the most recent meeting Inquiry, 1. Evidence for the
Layer Layer (meeting minutes/meeting invites) to verify the Inspection, most recent meeting
meeting took place and included members of the and/or (meeting
Blockchain Program management team. observation minutes/meeting
2. Through inspection of the documentation of the invites/emails)
assessment, verify the assessment was performed showing the meeting
and the results were documented. took place
2. Documentation of
management's
assessment on the
impact of the
Blockchain technology
to the audit scope
Operational Application 1. Obtain evidence for the most recent meeting Inquiry, 1. Evidence for the
Layer Layer (meeting minutes/meeting invites) to verify the Inspection, most recent meeting
meeting took place and included members of the and/or (meeting
Blockchain management team. observation minutes/meeting
2. Through inspection of an updated risk and audit invites/emails)
plan, verify changes and updates have been made showing the meeting
to reflect the Blockchain program. took place
2. Risk and audit plan
updated to address
Blockchain risks
Operational Blockchain 1. Inquire with management about the process in Inquiry, 1. Documentation of
Layer Consensus which appropriate consensus mechanisms are Inspection, the associated controls
Program agreed upon, implemented and controlled, and/or for a new Blockchain
Management 2. Obtain documentation of the associated observation consensus mechanism
controls. 2. Evidence of the
3. Through inspection of documentation review and approval
evidencing associated controls have been by the business and the
documented, verify these controls were reviewed Blockchain program
and approved by the business and the Blockchain management
program management.
Operational Blockchain 1. Inquire with management about the process in Inquiry,
Layer Consensus which appropriate consensus mechanisms are Inspection,
Program agreed upon, implemented and controlled. and/or
Management 2. Obtain documentation of the associated observation
controls.
3. Through inspection of documentation
evidencing associated controls have been
documented, verify these controls were reviewed
and approved by the business and the Blockchain
program management.
Operational Integration 1. Inquire with management about the process of Inquiry, 1. Integration plan used
Layer with off- ensuring alignment with new security Inspection, for initial integration
Blockchain requirements. and/or 2. Evidence showing
Systems and 2. Obtain the integration plan used for initial observation the integration plan is
Processes integration. monitored
3. Through inspection of the integration plan,
verify that there is evidence that the integration
plan is monitored by the Blockchain program
management.
Operational Integration 1. Obtain the documentation of the impact of Inquiry, 1. Documentation
Layer with off- software integration Inspection, showing the evaluation
Blockchain 2. Through inspection of the documentation, and/or performed of the
Systems and verify any impacts identified were appropriately observation impact of software
Processes evaluated. integration on the
3. Obtain evidence of the communicated results firm's existing
and through inspection, verify the results of the hardware
evaluation were reported to the Blockchain configurations
steering committee. 2. Evidence of
communication to the
Blockchain steering
committee
Operational Integration 1. Obtain the documentation of the impact of Inquiry, 1. Documentation
Layer with off- software integration. Inspection, showing the evaluation
Blockchain 2. Through inspection of the documentation, and/or performed of the
Systems and verify any impacts identified were appropriately observation impact of software
Processes evaluated. integration on the
3. Obtain evidence of the communicated results, firm's existing
and through inspection, verify the results of the hardware
evaluation were reported to the Blockchain configurations
steering committee. 2. Evidence of
communication to the
Blockchain steering
committee
Operational Integration 1. Obtain a listing of users with access to migrate Inquiry, 1. Listing of users with
Layer with off- the Blockchain process configurations. Inspection, access to migrate the
Blockchain 2. Obtain evidence for the most recent periodic and/or Blockchain process
Systems and review performed of access, and through observation configurations
Processes inspection verify access was restricted to 2. Evidence that a
personnel. periodic review was
3. Obtain the Operations policies and procedures performed of restricted
Blockchain evidencing the updates made to access and including
include integration with the Blockchain with evidence of the review
a date in which these updates were made. 3. Operations policies
4. Obtain evidence of the Blockchain change and procedures updated
being placed into production and the date in with the integration
which this occurred. with Blockchain with
5. Through inspection, verify the updates were the date in which the
made to the policies and procedures prior to the updates were made
change being placed into production. 4. Evidence of the
change being placed
into production
(change order ticket
including the date in
which the request was
processed and
completed)
Operational Integration 1. Obtain evidence of communication between Inquiry, 1. Evidence of
Layer with off- Business Unit IT management and the Blockchain Inspection, communication
Blockchain program management of a system identified as and/or between Business Unit
Systems and having Blockchain dependencies. observation IT management and the
Processes 2. Verify the Blockchain program management Blockchain program
performed an evaluation of the impact the legacy management for a
system change has on the Blockchain. system identified as
3. Obtain documentation verifying the details of having Blockchain
the evaluation were documented. dependencies
4. Obtain evidence of a processed change order 2. Evaluation
request to remove the Blockchain from production performed by the
and through inspection, verify the request was Blockchain program
completed. management
5. Obtain documentation of the back out plan and 3. Evidence that the
through inspection, verify that the back out plan Blockchain was
was enabled while a configuration change order removed from
was processed. production
4. Change order ticket
showing this request
was processed and
completed
5. Back out plan that
was enabled
Operational Integration 1. Inquire with management about the process of Inquiry, 1. The legacy system
Layer with off- updating the methodology to include integration Inspection, Software Development
Blockchain with Blockchain program management. and/or Lifecycle methodology
Systems and 2. Obtain documentation verifying change observation for change
Processes management processes have been updated with management processes
the date in which these updates were made. updated with
3. Obtain evidence of the changes made to the Blockchain with the
Blockchain and the date in which these changes date in which the
were made. updates were made
4. Through inspection, verify that the updates 2. Evidence of the
were made to the methodology prior to the changes made to the
changes being made. Blockchain impacted
5. Obtain the inventory listing and through system (change order
inspection, verify the listing includes functional ticket including the
use of all key interfaces and legacy systems date in which the
utilized by the Blockchain and that the listing is request was processed
properly maintained. and completed)
3. Inventory listing
with evidence of how
the listing is
maintained
Operational Integration 1. Obtain evidence of communication between Inquiry, 1. Evidence of
Layer with off- Business Unit Operations and the Blockchain Inspection, communication
Blockchain program management of a business process and/or between Business Unit
Systems and identified as having Blockchain dependencies. observation IT management and the
Processes 2. Verify the Blockchain program management Blockchain program
performed an evaluation of the impact the legacy management
system change has on the Blockchain. 2. Evaluation
3. Obtain evidence verifying the details of the performed by the
evaluation were documented. Blockchain program
4. Obtain evidence of a processed change order management
request to remove the Blockchain from production 3. Evidence that the
and through inspection, verify the request was Blockchain was
completed. removed from
5. Obtain documentation of the back out plan and production
through inspection, verify that the back out plan 4. Change order ticket
was enabled while a configuration change order showing this request
was processed. was processed
5. Back out plan that
was enabled
4.6 Transactional Layer Assessment Work Program In some embodiments, transaction layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain application stack/layer supporting business and transaction level processing.
The sub-risk categories, control and testing objectives, test procedures and request lists for Transactional Layer risk category are provided below in Tables 17-19.
TABLE 17
Risk Level
(L, M, H)
Risk Risk Risk (As
Category Domain Classification Number Risk Description applicable)
Transactional Smart Strategic, TL-SC1 Incorrect SC terms are not L, M, H
(Business) Contracts Operational, selected for execution.
(SC) Financial,
Compliance/
Legal,
Reputational
Transactional Smart Strategic, TL-SC2 SC terms and conditions are L, M, H
(Business) Contracts Operational, not inclusive of required
(SC) Financial, information or standard
Compliance/ terms and conditions.
Legal,
Reputational
Transactional Smart Strategic, TL-SC3 SC is executed with wrong/ L, M, H
(Business) Contracts Operational, incorrect participants or SC
(SC) Financial, does not include right/correct
Compliance/ participants.
Legal,
Reputational
Transactional Smart Strategic, TL-SC4 SC is not reviewed, appraised, L, M, H
(Business) Contracts Operational, and approved by appropriate
(SC) Financial, participants during or before
Compliance/ execution.
Legal,
Reputational
Transactional Smart Strategic, TL-SC5 SC is completed without L, M, H
(Business) Contracts Operational, execution of required terms
(SC) Financial, and conditions by all
Compliance/ participants.
Legal,
Reputational
Transactional Smart Strategic, TL-SC6 Required events (e.g. L, M, H
(Business) Contracts Operational, invoicing, payments, change
(SC) Financial, or ownership) are not initiated
Compliance/ and completed successfully
Legal, during or after SC execution.
Reputational
Transactional Smart Strategic, TL-SC7 Privileged access is not L, M, H
(Business) Contracts Operational, appropriately restricted, logged,
(SC) Financial, and monitored for Smart
Compliance/ Contracts, which can create a
Legal, risk of unauthorized access to
Reputational Smart Contracts by developers/
admins/database admins
Transactional Smart Strategic, TL-SC8 End-user access is not L, M, H
(Business) Contracts Operational, appropriately restricted, creating
(SC) Financial, the risk of unauthorized changes/
Compliance/ deployments/executions/updates/
Legal, modifications performed for the
Reputational Smart Contract and workflow
Transactional Smart Strategic, TL-SC9 Smart Contract development and L, M, H
(Business) Contracts Operational, change management process is
(SC) Financial, not in place and followed, which
Compliance/ may lead to unauthorized
Legal, unilateral actions by developers
Reputational to modify or remove Smart
Contract functions or introduce
unnecessary or insecure functions
Transactional Smart Strategic, TL-SC10 Smart Contract development and L, M, H
(Business) Contracts Operational, change management process is
(SC) Financial, not in place and followed, which
Compliance/ may lead to inappropriate and
Legal, incorrect terms and conditions
Reputational [e.g. timeline, pricing, resources,
invoicing, settlement, etc.]
defined for the Smart Contract
Transactional Smart Strategic, TL-SC11 Smart Contract development and L, M, H
(Business) Contracts Operational, change management process is
(SC) Financial, not in place and followed, which
Compliance/ may lead to inappropriate and
Legal, incorrect assets and services
Reputational defined for the Smart Contract
Transactional Smart Strategic, TL-SC12 Smart Contract development and L, M, H
(Business) Contracts Operational, change management process is
(SC) Financial, not in place and followed, which
Compliance/ may lead to inappropriate and
Legal, incorrect participants defined for
Reputational the Smart Contract
Transactional Smart Strategic, TL-SC13 Smart Contract development and L, M, H
(Business) Contracts Operational, change management process is
(SC) Financial, not in place and followed, which
Compliance/ may lead to unauthorized or
Legal, incorrect Smart Contracts being
Reputational introduced into the production
environment
Transactional Smart Strategic, TL-SC14 Unauthorized access to Blockchain L, M, H
(Business) Contracts Operational, metadata or PII by unauthorized
(SC) Financial, parties for development or testing
Compliance/ purposes
Legal,
Reputational
Transactional Smart Strategic, TL-SC15 Data is not retained for DLT inputs. L, M, H
(Business) Contracts Operational, PKIs. or other critical systems; lack
(SC) Financial, of availability limits backup and
Compliance/ recovery capability
Legal,
Reputational
Transactional Smart Strategic, TL-SC16 Input validation mechanisms for L, M, H
(Business) Contracts Operational, fields and records are not in place,
(SC) Financial, which may compromise the Smart
Compliance/ Contract execution
Legal,
Reputational
Transactional Smart Strategic, TL-SC17 Security mechanisms are not in L, M, H
(Business) Contracts Operational, place or effective in protecting
(SC) Financial, output (data), creating the risk
Compliance/ of unauthorized access or changes
Legal, made to output
Reputational
Transactional Smart Strategic, TL-SC18 Security mechanisms are not in L, M, H
(Business) Contracts Operational, place or effective in protecting
(SC) Financial, Smart Contracts mid their
Compliance/ exposure to unauthorized parties
Legal, via export and sharing
Reputational functionalities
Transactional Smart Strategic, TL-SC19 Mechanisms are not in place or L, M, H
(Business) Contracts Operational, effective in ensuring subsequent
(SC) Financial, Smart Contracts are only triggered
Compliance/ when appropriate and when needed
Legal,
Reputational
Transactional Smart Strategic, TL-SC20 Mechanisms are not in place or L, M, H
(Business) Contracts Operational, effective in ensuring subsequent
(SC) Financial, smart contracts, invoicing, billing
Compliance/ is triggered and processed
Legal, appropriately as and if needed
Reputational
Transactional Smart Strategic, TL-SC21 Mechanisms are not in place or L, M, H
(Business) Contracts Operational, effective in ensuring subsequent
(SC) Financial, movement of digital assets is
Compliance/ triggered and processed
Legal, appropriately as and if needed
Reputational
Transactional Smart Strategic, TL-SC22 Mechanisms are not in place or L, M, H
(Business) Contracts Operational, effective in ensuring subsequent
(SC) Financial, digital tokens are triggered and
Compliance/ processed appropriately as and
Legal, if needed
Reputational
Transactional Smart Strategic, TL-SC23 Monitoring mechanisms are not L, M, H
(Business) Contracts Operational, in place for Smart Contracts,
(SC) Financial, which can lead to non-detection
Compliance/ of Smart Contracts not performing
Legal, as intended in the production
Reputational environment
Transactional Smart Strategic, TL-SC24 Monitoring mechanisms are not in L, M, H
(Business) Contracts Operational, place for Smart Contracts, which
(SC) Financial, can create a risk of impaired
Compliance/ network performance or latency
Legal,
Reputational
Transactional Smart Strategic, TL-SC25 Monitoring mechanisms are not L, M, H
(Business) Contracts Operational, in place for Smart Contracts,
(SC) Financial, which can create a risk of the
Compliance/ Smart Contract not being
Legal, executed and completed as
Reputational per defined terms
Transactional Smart Strategic, TL-SC26 Monitoring mechanisms are not L, M, H
(Business) Contracts Operational, in place for Smart Contracts,
(SC) Financial, which can create a risk of the
Compliance/ Smart Contract not being retired
Legal, appropriately if necessary
Reputational
Transactional Smart Strategic, TL-SC27 Monitoring mcclianisms are not L, M, H
(Business) Contracts Operational, in place for Smart Contracts,
(SC) Financial, which can create a risk of the
Compliance/ Smart Contract being deployed,
Legal, modified, or changed by
Reputational unauthorized participants
Transactional Smart Strategic, TL-SC28 Smart Contract privacy is not L, M, H
(Business) Contracts Operational, maintained throughout the
(SC) Financial, Smart Contract lifecycle,
Compliance/ creating tire risk of private
Legal, information being divulged,
Reputational shared, or disseminated
Transactional Smart Strategic, TL-SC29 Interfaces are not configured L, M, H
(Business) Contracts Operational, to ensure all process data
(SC) Financial, transmissions within the
Compliance/ blockchain are complete,
Legal, accurate, and secure
Reputational
Transactional Smart Strategic, TL-SC30 Interfaces are not configured L, M, H
(Business) Contracts Operational, to ensure all process data
(SC) Financial, transmissions to off-chain
Compliance/ platforms or systems are
Legal, complete, accurate, and secure
Reputational
Transactional Smart Strategic, TL-SC31 Smart Contract arehitecture is L, M, H
(Business) Contracts Operational, unable to be updated/modified
(SC) Financial, and therefore docs not comply
Compliance/ with new requirements or
Legal, regulations or is vulnerable to
Reputational newly-discovered security issues
Transactional Smart Strategic, TL-SC32 Insufficient side chain safeguards L, M, H
(Business) Contracts Operational, increase risk of incidents leading
(SC) Financial, to loss or invalidation of assets or
Compliance/ transactions related to Smart
Legal, Contracts
Reputational
Transactional Digital Strategic, TL-DA1 Incorrectly DA onboarding may L, M, H
(Business) Assets Operational, cause delay or compromise
(DA) Financial, transactional level processing.
Compliance/
Legal,
Reputational
Digital Strategic, TL-DA2 DA ownership is transferred L, M, H
Assets Operational, incorrectly which may compromise
(DA) Financial, transactional level processing.
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DA3 DA is not managed and maintained L, M, H
(Business) Assets Operational, appropriately during its lifecycle.
(DA) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DA4 DA is not retired appropriately at L, M, H
(Business) Assets Operational, the end of the lifecycle.
(DA) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DA5 Privileged access is not L, M, H
(Business) Assets Operational, appropriately restricted, logged,
(DA) Financial, and monitored for Digital Assets,
Compliance/ which can lead to unauthorized
Legal, access
Reputational
Transactional Digital Strategic, TL-DA6 End-user access is not appropriately L, M, H
(Business) Assets Operational, restricted, creating the risk of
(DA) Financial, unauthorized changes/deployments/
Compliance/ executions/updates/modifications
Legal, performed for the Digital Assets
Reputational and workflow
Transactional Digital Strategic, TL-DA7 Digital Assets are not configured L, M, H
(Business) Assets Operational, with strong login credentials and
(DA) Financial, account security protocols to
Compliance/ restrict unauthorized access
Legal,
Reputational
Transactional Digital Strategic, TL-DA8 Digital Assets are stored in an L, M, H
(Business) Assets Operational, unsecure environment, and hot/
(DA) Financial, warm/cold risk factors systemic
Compliance/ to each Digital Asset platform
Legal, are not taken into account,
Reputational creating greater risks to Digital
Asset operations and security
of transaction data
Transactional Digital Strategic, TL-DA9 Participants are not L, M, H
(Business) Assets Operational, appropriately and correctly
(DA) Financial, defined which can lead to
Compliance/ unauthorized access or
Legal, operation of the Digital Asset
Reputational
Transactional Digital Strategic, TL-DA10 Digital Assets are not L, M, H
(Business) Assets Operational, appropriately or correctly
(DA) Financial, protected, managed, and
Compliance/ monitored throughout
Legal, their life cycle
Reputational
Transactional Digital Strategic, TL-DA11 Unauthorized or incorrect L, M, H
(Business) Assets Operational, Digital Asset platforms tire
(DA) Financial, introduced, compromising the
Compliance/ security of the organization's
Legal, Digital Asset environment
Reputational
Transactional Digital Strategic, TL-DA12 Digital Asset software is not L, M, H
(Business) Assets Operational, updated in accordance with
(DA) Financial, required updates, leading to
Compliance/ version mismatching and
Legal, potential compromises to
Reputational security or operational limitations
Transactional Digital Strategic, TL-DA13 Digital Asset management L, M, H
(Business) Assets Operational, platforms are not configured
(DA) Financial, with recover) procedures to
Compliance/ recover loss of data and
Legal, information
Reputational
Transactional Digital Strategic, TL-DA14 Mechanisms are not in place L, M, H
(Business) Assets Operational, or effective in ensuring Digital
(DA) Financial, Asset transactions are triggered
Compliance/ as and if needed
Legal,
Reputational
Transactional Digital Strategic, TL-DA15 Monitoring mechanisms are not L, M, H
(Business) Assets Operational, in place for Digital Assets, which
(DA) Financial, can lead to non-detection of
Compliance/ Digital Assets not performing as
Legal, intended in the production
Reputational environment
Transactional Digital Strategic, TL-DA16 Monitoring mechanisms are not L, M, H
(Business) Assets Operational, in place for Digital Assets,
(DA) Financial, which can create a risk of
Compliance/ impaired network performance
Legal, or latency
Reputational
Transactional Digital Strategic, TL-DA17 Monitoring mechanisms tire L, M, H
(Business) Assets Operational, not in place for Digital Assets,
(DA) Financial, which can create a risk of a
Compliance/ Digital Asset not being utilized
Legal, per defined terms
Reputational
Transactional Digital Strategic, TL-DA18 Monitoring mechanisms are L, M, H
(Business) Assets Operational, not in place for Digital Assets,
(DA) Financial, which can create a risk of the
Compliance/ Digital Asset not being retired
Legal, appropriately if neccssary
Reputational
Transactional Digital Strategic, TL-DA19 Monitoring mechanisms are L, M, H
(Business) Assets Operational, not in place for Digital Assets,
(DA) Financial, which can create a risk of the
Compliance/ Digital Asset being utilized,
Legal, modified, or changed by
Reputational unauthorized participants
Transactional Digital Strategic, TL-DA20 Digital Asset privacy is not L, M, H
(Business) Assets Operational, maintained throughout the
(DA) Financial, Digital Asset lifecycle, creating
Compliance/ the risk of private information
Legal, being divulged, shared, or
Reputational disseminated
Transactional Digital Strategic, TL-DA21 Interfaces are not configured to L, M, H
(Business) Assets Operational, ensure all process data
(DA) Financial, transmissions within the
Compliance/ blockchain are complete,
Legal, accurate, and secure
Reputational
Transactional Digital Strategic, TL-DA22 Interfaces are not configured to L, M, H
(Business) Assets Operational, ensure all process data
(DA) Financial, transmissions to off-chain
Compliance/ platforms or systems are
Legal, complete, accurate, and secure
Reputational
Transactional Digital Strategic, TL-DA23 Without price fluctuation L, M, H
(Business) Assets Operational, monitoring and defined
(DA) Financial, response/action plan, assets,
Compliance/ contracts, tokens can be
Legal, processed with incorrect
Reputational value at a given point in time
Transactional Digital Strategic, TL-DA24 Fluctuations in prices for L, M, H
(Business) Assets Operational, commodity items like Digital
(DA) Financial, Asset storage create
Compliance/ opportunities for sunk costs
Legal, or deadweight loss
Reputational expenditures
Transactional Digital Strategic, TL-DA25 Digital Assets within the L, M, H
(Business) Assets Operational, organization are not linked
(DA) Financial, with soft or intangible assets
Compliance/ (i.e. human resources)
Legal, causing lack of operational
Reputational alignment across the
organization
Transactional Digital Strategic, TL-DA26 Digital Assets within the L, M, H
(Business) Assets Operational, organization are not linked
(DA) Financial, with other real world assets
Compliance/ (i.e. real estate, property,
Legal, etc.) causing lack of
Reputational operational alignment across
the organization
Transactional Digital Strategic, TL-DA27 The existence of physical/ L, M, H
(Business) Assets Operational, logical assets is not tracked
(DA) Financial, or managed on a regular
Compliance/ basis, causing inaccurate
Legal, and incomplete
Reputational representation of physical
assets in a digital form
Transactional Digital Strategic, TL-DA28 The organization's legacy L, M, H
(Business) Assets Operational, system accounts are not
(DA) Financial, linked with DLT associated
Compliance/ Digital Assets, causing lack
Legal, of operational alignment
Reputational across the organization
Transactional Digital Strategic, TL-DT1 Participants are not on- L, M, H
(Business) Tokens Operational, boarded for DC transactions.
(DT) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT2 Account balance cannot L, M, H
(Business) Tokens Operational, support DC transaction
(DT) Financial, request for processing.
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT3 DC-in requests are not L, M, H
(Business) Tokens Operational, processed correctly.
(DT) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT4 DC-out requests are not L, M, H
(Business) Tokens Operational, processed correctly.
(DT) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT5 DC duplicate transactions L, M, H
(Business) Tokens Operational, are processed.
(DT) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT6 DC transactions are L, M, H
(Business) Tokens Operational, approved.
(DT) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT7 DC transaction information L, M, H
(Business) Tokens Operational, is missing which may
(DT) Financial, compromise transaction
Compliance/ processing.
Legal,
Reputational
Transactional Digital Strategic, TL-DT8 Address is not generated or L, M, H
(Business) Tokens Operational, shared with participants for
(DT) Financial, DC transactions.
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT9 Cancelled or failed L, M, H
(Business) Tokens Operational, transactions are not tracked
(DT) Financial, or processed correctly.
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT10 DC is not moved from one L, M, H
(Business) Tokens Operational, participant to the other (e.g.
(DT) Financial, payor and payee) correctly
Compliance/ and in a timely manner.
Legal,
Reputational
Transactional Digital Strategic, TL-DT11 DC is not evaluated correctly L, M, H
(Business) Tokens Operational, relative to underlying asset or
(DT) Financial, currency.
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT12 Privileged access is not L, M, H
(Business) Tokens Operational, appropriately restricted,
(DT) Financial, logged, and monitored for
Compliance/ Digital Tokens, which can
Legal, lead to unauthorized access
Reputational
Transactional Digital Strategic, TL-DT13 End-user access is not L, M, H
(Business) Tokens Operational, appropriately restricted,
(DT) Financial, which can lead to
Compliance/ unauthorized changes/
Legal, updates/modifications
Reputational performed for the Digital
Tokens and workflow
Transactional Digital Strategic, TL-DT14 Digital Tokens are not L, M, H
(Business) Tokens Operational, configured with strong
(DT) Financial, login credentials and
Compliance/ account security protocols
Legal, to restrict unauthorized
Reputational access
Transactional Digital Strategic, TL-DT15 Digital Token development L, M, H
(Business) Tokens Operational, and change management
(DT) Financial, process is not in place and
Compliance/ followed, which may lead to
Legal, inappropriate and incorrect
Reputational participants defined for
authorized use of Digital Tokens
Transactional Digital Strategic, TL-DT16 Digital Tokens are not L, M, H
(Business) Tokens Operational, appropriately or correctly
(DT) Financial, protected, managed, and
Compliance/ monitored throughout their
Legal, life
Reputational
Transactional Digital Strategic, TL-DT17 Digital Tokens are not L, M, H
(Business) Tokens Operational, monitored appropriately
(DT) Financial, throughout their life cycle
Compliance/ causing inaccurate records
Legal, for when tokens were created,
Reputational converted, updated, and retired
Transactional Digital Strategic, TL-DT18 Digital Token development and L, M, H
(Business) Tokens Operational, change management process is
(DT) Financial, not in place and followed, which
Compliance/ may lead to unauthorized or
Legal, incorrect Digital Tokens being
Reputational introduced into the operational
environment
Transactional Digital Strategic, TL-DT19 Lack of a clearly defined Digital L, M, H
(Business) Tokens Operational, Token platform can potentially
(DT) Financial, endanger the organization's
Compliance/ transactional data or create
Legal, unauthorized operational
Reputational redundancies
Transactional Digital Strategic, TL-DT20 Digital Token platforms are not L, M, H
(Business) Tokens Operational, configured with recovery
(DT) Financial, procedures to recover loss of
Compliance/ data and information
Legal,
Reputational TL-DT21 Ownership of assets linked to L, M, H
Transactional Digital Strategic, Digital Tokens is not defined
(Business) Tokens Operational, or managed by the organization
(DT) Financial,
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT22 Data is not retained for DLT L, M, H
(Business) Tokens Operational, inputs, PKIs, or other critical
(DT) Financial, systems; lack of availability
Compliance/ limits backup and recovery
Legal, capability
Reputational
Transactional Digital Strategic, TL-DT23 Mechanisms are not in place L, M, H
(Business) Tokens Operational, or effective in ensuring Digital
(DT) Financial, Token transactions are triggered
Compliance/ as and if needed
Legal,
Reputational
Transactional Digital Strategic, TL-DT24 Digital Tokens are not L, M, H
(Business) Tokens Operational, monitored to ensure tokens are
(DT) Financial, utilized appropriately for
Compliance/ authorized transactions or
Legal, operations
Reputational
Transactional Digital Strategic, TL-DT25 Digital Token ownership and L, M, H
(Business) Tokens Operational, management of ownership is
(DT) Financial, not monitored appropriately
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT26 The DLT and off-chain ledger L, M, H
(Business) Tokens Operational, or accounting mechanisms
(DT) Financial, are not monitored,
Compliance/ compromising the ability to
Legal, accurately track usage of
Reputational tokens during normal
operations and transactions
Transactional Digital Strategic, TL-DT27 Monitoring mechanisms are L, M, H
(Business) Tokens Operational, not in place for Digital Tokens,
(DT) Financial, which can create a risk of Digital
Compliance/ Tokens being utilized, modified,
Legal, or changed by unauthorized
Reputational participants
Transactional Digital Strategic, TL-DT28 Interfaces are not configured to L, M, H
(Business) Tokens Operational, ensure all process data
(DT) Financial, transmissions within the
Compliance/ blockchain are complete, accurate,
Legal, and secure
Reputational
Transactional Digital Strategic, TL-DT29 Interfaces are not configured to L, M, H
(Business) Tokens Operational, ensure all process data
(DT) Financial, transmissions to off-chain
Compliance/ platforms or systems are complete,
Legal, accurate, and secure
Reputational
Transactional Digital Strategic, TL-DT30 Without price fluctuation L, M, H
(Business) Tokens Operational, monitoring and defined response/
(DT) Financial, action plan, tokens, contracts,
Compliance/ tokens can be processed with
Legal, incorrect value at a given point
Reputational in time
Transactional Digital Strategic, TL-DT31 Fluctuations in prices for L, M, H
(Business) Tokens Operational, commodity items like Digital
(DT) Financial, Token storage create opportunities
Compliance/ for sunk costs or deadweight loss
Legal, expenditures
Reputational
Transactional Digital Strategic, TL-DT32 The existence of digital tokens or L, M, H
(Business) Tokens Operational, funds used for blockchain
(DT) Financial, transactions are not validated
Compliance/
Legal,
Reputational
Transactional Digital Strategic, TL-DT33 Digital tokens are not configured L, M, H
(Business) Tokens Operational, with strong login credentials and
(DT) Financial, account security protocols to
Compliance/ restrict unauthorized access
Legal,
Reputational
Transactional Digital Strategic, TL-DW01 Privileged access is not L, M, H
(Business) Wallets Operational, appropriately restricted, logged,
(DW) Financial, and monitored for Digital Wallets,
Compliance/ which can lead to unauthorized
Legal, access to Digital Wallets
Reputational
Transactional Digital Strategic, TL-DW02 End-user access is not L, M, H
(Business) Wallets Operational, appropriately restricted, creating
(DW) Financial, the risk of unauthorized changes/
Compliance/ deployments/executions/updates/
Legal, modifications performed for
Reputational Digital Wallets and workflow
Transactional Digital Strategic, TL-DW03 Digital Wallets are not configured L, M, H
(Business) Wallets Operational, with strong login credentials and
(DW) Financial, account security protocols to
Compliance/ restrict unauthorized access
Legal,
Reputational
Transactional Digital Strategic, TL-DW04 Digital Wallets, ledgers, and L, M, H
(Business) Wallets Operational, access points are stored in an
(DW) Financial, insecure environment, and hot/
Compliance/ warm/cold risk factors sy stemic
Legal, to each wallet platform are not
Reputational taken into account, creating
greater risks to Digital Wallet
operations and security of
transaction data
Transactional Digital Strategic, TL-DW05 Digital Wallet development L, M, H
(Business) Wallets Operational, and change management
(DW) Financial, process is not in place and
Compliance/ followed, which may lead to
Legal, inappropriate and incorrect
Reputational participants defined for the
Digital Wallet
Transactional Digital Strategic, TL-DW06 Digital Wallet development and L, M, H
(Business) Wallets Operational, change management process is
(DW) Financial, not in place and followed, which
Compliance/ may lead to unauthorized or
Legal, incorrect Digital Wallets being
Reputational introduced into the environment
Transactional Digital Strategic, TL-DW07 Digital Wallet software is not L, M, H
(Business) Wallets Operational, updated in accordance w ith
(DW) Financial, required updates, leading to
Compliance/ version mismatching and
Legal, potential compromises to
Reputational security or operational limitations
Transactional Digital Strategic, TL-DW08 Lack of a clearly defined Digital L, M, H
(Business) Wallets Operational, Wallet platform can potentially
(DW) Financial, endanger the organization's
Compliance/ transactional data, create
Legal, unauthorized operational
Reputational redundancies, or inhibit consistent
and effective risk management of
specific Digital Wallet platforms
(i.e. software, hardware, ledger, etc.)
Transactional Digital Strategic, TL-DW09 Digital Wallet platforms are not L, M, H
(Business) Wallets Operational, configured with recovery
(DW) Financial, procedures to recover lost data
Compliance/ and information
Legal,
Reputational
Transactional Digital Strategic, TL-DW10 Data is not retained for DLT L, M, H
(Business) Wallets Operational, inputs, PKIs, or other critical
(DW) Financial, systems, lack of availability limits
Compliance/ backup and recovery capability
Legal,
Reputational
Transactional Digital Strategic, TL-DW11 Input validation mechanisms for L, M, H
(Business) Wallets Operational, fields and records are not in place,
(DW) Financial, which may compromise the
Compliance/ Digital Wallet's operations
Legal,
Reputational
Transactional Digital Strategic, TL-DW12 Security mechanisms are not in L, M, H
(Business) Wallets Operational, place or effective in protecting
(DW) Financial, output (data), creating the risk of
Compliance/ unauthorized access or changes
Legal, made to output
Reputational
Transactional Digital Strategic, TL-DW13 Security mechanisms are not in L, M, H
(Business) Wallets Operational, place or effective in protecting
(DW) Financial, Digital Wallets and their exposure
Compliance/ to unauthorized parties via export
Legal, and sharing functionalities
Reputational
Transactional Digital Strategic, TL-DW14 Mechanisms are not in place or L, M, H
(Business) Wallets Operational, effective in ensuring Digital Wallet
(DW) Financial, transactions are only triggered
Compliance/ when appropriate and when needed
Legal,
Reputational
Transactional Digital Strategic, TL-DW15 Mechanisms are not in place or L, M, H
(Business) Wallets Operational, effective in ensuring off-chain
(DW) Financial, invoicing and billing is triggered
Compliance/ and processed by authorized
Legal, participants appropriately as and
Reputational if needed
Transactional Digital Strategic, TL-DW16 Mechanisms are not in place or L, M, H
(Business) Wallets Operational, effective in ensuring digital token
(DW) Financial, transactions are triggered and
Compliance/ processed appropriately as and
Legal, if needed
Reputational
Transactional Digital Strategic, TL-DW17 Mechanisms are not in place or L, M, H
(Business) Wallets Operational, effective in ensuring subsequent
(DW) Financial, Digital Wallet transactions are
Compliance/ triggered and processed by
Legal, authorized participants and
Reputational appropriately as and if needed
Transactional Digital Strategic, TL-DW18 Monitoring meclianisms are not L, M, H
(Business) Wallets Operational, in place for Digital Wallets,
(DW) Financial, which can lead to non-detection
Compliance/ of Digital Wallets not
Legal, performing as intended in the
Reputational environment
Transactional Digital Strategic, TL-DW19 Monitoring mechanisms are L, M, H
(Business) Wallets Operational, not in place for Digital Wallets,
(DW) Financial, which can create a risk of
Compliance/ impaired network performance
Legal, or latency
Reputational
Transactional Digital Strategic, TL-DW20 Mechanisms are not in place L, M, H
(Business) Wallets Operational, to monitor Digital Wallet
(DW) Financial, transactions and ensure
Compliance/ transactions are executed
Legal, per defined terms
Reputational
Transactional Digital Strategic, TL-DW21 Monitoring mechanisms are L, M, H
(Business) Wallets Operational, not in place for Digital Wallets,
(DW) Financial, which can create a risk of the
Compliance/ Digital Wallet not being retired
Legal, appropriately if necessary
Reputational
Transactional Digital Strategic, TL-DW22 Monitoring mechanisms are L, M, H
(Business) Wallets Operational, not in place for Digital Wallets,
(DW) Financial, which can create a risk of the
Compliance/ Digital Wallet being utilized,
Legal, modified, or changed by
Reputational unauthorized participants
Transactional Digital Strategic, TL-DW23 Digital Wallet privacy is not L, M, H
(Business) Wallets Operational, maintained throughout the
(DW) Financial, Digital Wallet lifecycle,
Compliance/ creating the risk of private
Legal, information being divulged,
Reputational shared, or disseminated
Transactional Digital Strategic, TL-DW24 Interfaces are not configured L, M, H
(Business) Wallets Operational, to ensure all process data
(DW) Financial, transmissions within the
Compliance/ blockchain are complete,
Legal, accurate, and secure
Reputational
Transactional Digital Strategic, TL-DW25 Interfaces are not configured L, M, H
(Business) Wallets Operational, to ensure all process data
(DW) Financial, transmissions to off-chain
Compliance/ platforms or systems are
Legal, complete, accurate, and secure
Reputational
Transactional Digital Strategic, TL-DW26 Mechanisms are not in place L, M, H
(Business) Wallets Operational, or effective in ensuring Digital
(DW) Financial, Wallets are configured with
Compliance/ appropriate transaction
Legal, thresholds to prevent failed
Reputational detection of transferred funds
Transactional Digital Strategic, TL-DW27 Security mechanisms are not L, M, H
(Business) Wallets Operational, in place for Digital Wallets,
(DW) Financial, compromising private keys or
Compliance/ PKIs, which may result in
Legal, breaches of Digital Wallet
security or risk of unauthorized
access to assets stored on the
wallet platform
Transactional Digital Strategic, TL-DW28 The organization's legacy L, M, H
(Business) Wallets Operational, system accounts are not linked
(DW) Financial, with PKIs or DLTs associated
Compliance/ with the Digital Wallet, causing
Legal, lack of operational alignment
Reputational across the organization
Transactional Clearing Strategic, TL-CS1 Movement of underlying asset L, M, H
(Business) and Operational, or currency is not synchronized
Settle- Financial, with books of records.
ment Compliance/
Legal,
Reputational
Transactional Buisness Strategic, TL-BU1 Transactions are not approved. L, M, H
(Business) Use case Operational,
transactions Financial,
Compliance/
Legal,
Reputational
Transactional Buisness Strategic, TL-BU2 Transactions are not processed L, M, H
(Business) Use case Operational, accurately, completely or within
transactions Financial, approved guidelines.
Compliance/
Legal,
Reputational
TABLE 18
In-scope/
Out-of-
Scope
(TBD—As
Risk per
Category Domain Control/Test Objective Control Description engagement)
Transactional Smart Control(s) is in place to ensure correct Inquire management of the In-scope
(Business) Contracts template is used for SC execution. control activities that are
(SC) in place to meet applicable
risks and relevant control
objectives.
Transactional Smart Control(s) is in place to ensure that required Inquire management of the In-scope
(Business) Contracts information or standard terms and conditions control activities that are
(SC) are included in the SC before execution. in place to meet applicable
risks and relevant control
objectives.
Transactional Smart Control(s) is in place to ensure that required Inquire management of the In-scope
(Business) Contracts andcorrect participants associated with control activities that are
(SC) the SC before execution. in place to meet applicable
risks and relevant control
objectives.
Transactional Smart Control(s) is in place to ensure that SC is Inquire management of the In-scope
(Business) Contracts reviewed, appraised, and approved by control activities that are
(SC) appropriate participants. in place to meet applicable
risks and relevant control
objectives.
Transactional Smart Control(s) is in place to ensure that SC is Inquire management of the In-scope
(Business) Contracts executed after terms and conditions are control activities that are
(SC) met by all participants. in place to meet applicable
risks and relevant control
objectives.
Transactional Smart Control(s) is in place to ensure that required Inquire management of the In-scope
(Business) Contracts events (e.g. invoicing, payments, change or control activities that are
(SC) ownership) are initiated and completed in place to meet applicable
successfully during or after SC execution. risks and relevant control
Upon consensus, smart contracts auto- objectives.
matically executes the exchange of
position and cash in a complete, accurate
and timely manner.
Transactional Digital Control(s) is in place to ensure that DAs are Inquire management of the In-scope
(Business) Assets classified and created correctly and control activities that are
(DA) successfully for transactional level in place to meet applicable
processing. risks and relevant control
objectives.
Digital Control(s) is in place to ensure that DA Inquire management of the In-scope
Assets ownership is transferred to the right/correct control activities that are
(DA) participants in a timely manner. in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that DA is Inquire management of the In-scope
(Business) Assets managed and maintained (e.g. classification, control activities that are
(DA) valuation, and handovers) appropriately in place to meet applicable
throughout the lifecycle. risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that DA is Inquire management of the In-scope
(Business) Assets retired appropriately at the end of the control activities that are
(DA) lifecycle. in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that valid Inquire management of the In-scope
(Business) Currency participants are on-boarded and assigned control activities that are
(DC) with a digital wallet for DC transactions. in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that a payor Inquire management of the In-scope
(Business) Currency account balance is checked and verified to control activities that are
(DC) validate that sufficient DC is available before in place to meet applicable
the transaction is processed or completed. risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that DC-in Inquire management of the In-scope
(Business) Currency (Cash-in) requests are processed completely control activities that are
(DC) and accurately. in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that DC-out Inquire management of the In-scope
(Business) Currency (Cash-out) requests are processed completely control activities that are
(DC) and accurately. in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that a Inquire management of the In-scope
(Business) Currency duplicate DC transactions are not processed. control activities that are
(DC) in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that a DC Inquire management of the In-scope
(Business) Currency transactions are approved appropriately for control activities that are
(DC) processing. in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that a DC Inquire management of the In-scope
(Business) Currency transactions contain required information for control activities that are
(DC) processing. in place to meet applicable
risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that a valid Inquire management of the In-scope
(Business) Currency unique address is generated and shared with control activities that are
(DC) appropriate participants in safe and secure in place to meet applicable
manner for DC transactions processing. risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that cancelled Inquire management of the In-scope
(Business) Currency and failed transactions are monitored, control activities that are
(DC) processed and recorded in the books in place to meet applicable
accurately. risks and relevant control
objectives.
Transactional Digital Control(s) is in place to ensure that DC is Inquire management of the In-scope
(Business) Currency moved from one participant to the other (e.g. control activities that are
(DC) payee and payor) correctly and in a timely in place to meet applicable
manner. Also, the movement of DC is risks and relevant control
recorded in the books of records accurately. objectives.
Transactional Digital Control(s) is in place to ensure that DC is Inquire management of the In-scope
(Business) Currency evaluated correctly relative to underlying control activities that are
(DC) asset or currency in a timely manner. in place to meet applicable
risks and relevant control
objectives.
Transactional Clearing Control(s) is in place to ensure that books Inquire management of the In-scope
(Business) and of records are updated when the underlying control activities that are
Settlement asset or currency is processed. Reconcil- in place to meet applicable
iation and verification between books of risks and relevant control
records and underlying asset or currency objectives.
position is performed to validate
integrity, accuracy and completeness of
transactional and business information.
Control(s) is in place to ensure that
trades/transactions processing meet the
following financial statements assertion
requirements:
1—Rights and obligations
2—Completeness, accuracy, cutoff
3—Existence
4—Valuation
Transactional Business Control(s) is in place to ensure that business Inquire management of the In-scope
(Business) Use case transactions are authorized and executed in control activities that are
transactions accordance with approved guidelines. in place to meet applicable
risks and relevant control
objectives.
Transactional Business Control(s) is in place to ensure that trades/ Inquire management of the In-scope
(Business) Use case transactions meet the following financial control activities that are
transactions statements assertion requirements: in place to meet applicable
1—Rights and obligations risks and relevant control
2—Completeness, accuracy, cutoff objectives.
3—Existence
4—Valuation
TABLE 19
Re-
Test Type quest
Risk (TBD—As List
Category Domain Test Procedure (#) per engagement) (#)
Transactional Smart Based on the inquiry of the Inquiry, Inspection,
(Business) Contracts management regarding the control observation, and/or
(SC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Smart Based on the inquiry of the Inquiry, Inspection,
(Business) Contracts management regarding the control observation, and/or
(SC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Smart Based on the inquiry of the Inquiry, Inspection,
(Business) Contracts management regarding the control observation, and/or
(SC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Smart Based on the inquiry of the Inquiry, Inspection,
(Business) Contracts management regarding the control observation, and/or
(SC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Smart Based on the inquiry of the Inquiry, Inspection,
(Business) Contracts management regarding the control observation, and/or
(SC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Smart Based on the inquiry of the Inquiry, Inspection,
(Business) Contracts management regarding the control observation, and/or
(SC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Assets management regarding the control observation, and/or
(DA) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Digital Based on the inquiry of the Inquiry, Inspection,
Assets management regarding the control observation, and/or
(DA) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Assets management regarding the control observation, and/or
(DA) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Assets management regarding the control observation, and/or
(DA) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Digital Based on the inquiry of the Inquiry, Inspection,
(Business) Currency management regarding the control observation, and/or
(DC) activities in place assessment Automated
results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Clearing Based on the inquiry of the Inquiry, Inspection,
(Business) and management regarding the control observation, and/or
Settle- activities in place assessment Automated
ment results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Business Based on the inquiry of the Inquiry, Inspection,
(Business) Use case management regarding the control observation, and/or
transac- activities in place assessment Automated
tions results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
Transactional Business Based on the inquiry of the Inquiry, Inspection,
(Business) Use case management regarding the control observation, and/or
transac- activities in place assessment Automated
tions results test procedures will be
designed and data parameters will
be identified to configure and
operationalize the Blockchain
Auditing software
In one or more embodiments, the blockchain risk framework is designed to produce testing procedures that align with a technology stack associated with a blockchain. FIG. 5A illustrates a correspondence between the testing procedures produced by a risk framework and a technology stack of a blockchain system according to examples of the disclosure. In FIG. 5A, a block chain use-case technology stack can include multiple technology stacks that are integrated together to form the overall blockchain computing system. For instance in the example of FIG. 6, a block-chain use-case technology stack 600 can include an application layer 502, encryption (cryptography) layer 506, a permissioned or unpermissioned network layer (i.e., operational layer) 508, a shared data layer 510, a commercial API layer 512, and an overlay network layer 514.
In one or more examples, an application layer 502 can include decentralized applications (i.e., a digital application or program) that can be run by many users or nodes on a decentralized network with consensus and other trustless protocols. They can be designed to avoid any single point of failure. The applications in the application layer provide workflow and processing logic to execute transactional activity using shared communications protocols and interface methods used by hosts in a communications network.
In one or more examples, an encryption (cryptography) layer 506 can include cryptography used to cipher (encrypt) and de-cipher (decrypt) information by using a mathematical function or algorithm. Encryption can refer to the process of transforming information so it is unintelligible/inaccessible/unreadable to anyone but the intended recipient. Decryption is the process of transforming encrypted information so that it is intelligible/accessible/readable again.
In one or more examples, a permissioned or unpermissioned network layer 508 can refer to both permissioned networks and unpermissioned networks. Unpermissioned networks can refer to an open blockchain network that anyone can join and participate in. The community operates and administers the blockchain, and one or more participants can provide consensus. Any user can join a permissionless network, i.e., exchanging digital currency on a public currency exchange. A permissioned network refers to a blockchain model that requires permission to join, read, write to, operate and administer. Multiple participants administer the blockchain under consortium or group leadership. There may be restrictions on how participants can contribute to the system state or consensus of transactions. In one or more examples network layer 508 can also include private blockchains. In a private blockchain, only a centralized entity or single participant has permission to write to the blockchain. Platform architects can decide how to assign permissions.
In one or more examples, shared data layer 510 can include organized collections of data that are stored and accessed electronically. In one or more example a commercial API layer 512 can include elements dealing with an interface in software that can act as a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans and combinations of these. Finally, in one or more examples, an overlay network layer 514 includes different types of LAN and WAN networks that are used to access the blockchain system. The network layer provides the means of transferring variable-length network packets from a source to a destination host via one or more networks.
One or more of the risk categories described above can correspond to one or more layers of the stack 500. For instance, in the example of FIG. 5A, transaction layer risks 518 can correspond to the application layer 502 of the stack 500. This can mean that test procedures created in response to the “transactional layer” risk framework can create test procedures that validate the application layer of the blockchain use-case stack 500. Likewise, blockchain architecture layer risks 514 can generate test procedures that test and validate the decentralized protocols layer 504, and the encryption layer 506. The operation layer risks 520 can generate tests that can validate and test permissioned network layer 508. Finally the infrastructure layer risks 516 of the risk framework can create test procedures that can validate and test shared data layer 510, commercial API layer 512, and overlay network 514.
FIG. 5B illustrates sub-categories corresponding to each risk framework category according to examples of the disclosure. As illustrated in FIG. 5B, each category of risk can include one or more subcategories. For instance, the governance and oversight risk category 530 can include one or more sub-categories including (but not limited to): business objectives, program sponsorship, leadership commitment, MIS and metrics, program management, operational and capital expenditure oversight, and project management. The cyber security risk category 530 can include one or more sub-categories including (but not limited to): cloud security, data security, data privacy, penetration testing, programming security, network security, patch vulnerability, threat detection, and threat response. The infrastructure risk category 534 can include one or more sub-categories including (but not limited to): servers and databases configuration, ITGCs, business continuity and disaster recovery, and IT asset management. The transactional layer risk category 536 can include one or more sub-categories including (but not limited to): smart contracts, digital assets, digital currency, cleaning and settlement, business use and case transactions. The operation layer risk category 538 can include one or more sub-categories including (but not limited to): permissioned network management, participant over boarding and off-boarding, application layer, blockchain consensus program management, and integration with off-blockchain systems and processes. Finally the blockchain architecture risk category 540 can include one or more sub-categories including (but not limited to): blockchain platform and protocol configuration, hardware security modules, signature management, cryptography, scalability, and availability.
In some embodiments, the results (i.e. testing procedures and parameters) of an assessment performed using the blockchain risk framework can be used to consolidate the audit and compliance activities into categories by nature of activity at the transaction layer and embed them into an validating software/tool. By drawing data from the underlying blockchain ledger as well as from other up and down stream systems affecting the use case, any and all necessary audit or assurance based procedures can be fully automate and active transparency for them on a real time basis (or some other cadence if preferred) can be provided to the practitioner.
As illustrated in the discussion above, the risk framework can provide a user interface that translates a user's blockchain auditing preferences into tangible tests and procedures that are then used to perform real-time continuous monitoring of the block chain system. FIG. 6 illustrates an exemplary process for generating blockchain test procedures according to examples of the disclosure. The process 600 described with respect to FIG. 6 can be performed on a computing system that includes a display and devices that are configured to accept input from a user such as a keyboard, touchpad, mouse, etc.
The process can begin at step 602, wherein the user is presented with the risk framework and is prompted by the risk framework to specify a risk level associated with each risk category and sub-category as described above. Once the user specifies the risk levels, the process can move to step 604 wherein the user can be presented with a series of controls of the blockchain that relate to the risks identified in step 602 (as described above). When presented with the series of controls, the user can then be prompted by the risk framework to input which controls are to be in-scope of the assessment, and which ones are to be considered out of scope as described above.
Once the user indicates which controls are in scope versus out of scope at step 604, the process can move to step 606, wherein the risk framework generates one or more test procedures based on the user's inputs into the risk framework. Once the tests are generated at step 606, the process can move to step 608 wherein the test procedures are transmitted to an external user. In one or more examples, transmitting the test procedures can include generating a planning file that can be used by a validation software (like the one described with respect to FIG. 4) to perform real-time and continuous validation of a blockchain.
FIG. 7 illustrates an example of a computing device in accordance with one embodiment. Device 700 can be a host computer connected to a network. Device 700 can be a client computer or a server. As shown in FIG. 7, device 700 can be any suitable type of microprocessor-based device, such as a personal computer, workstation, server, or handheld computing device (portable electronic device) such as a phone or tablet. The device can include, for example, one or more of processor 710, input device 720, output device 730, storage 740, and communication device 760. Input device 720 and output device 730 can generally correspond to those described above and can either be connectable or integrated with the computer.
Input device 720 can be any suitable device that provides input, such as a touch screen, keyboard or keypad, mouse, or voice-recognition device. Output device 730 can be any suitable device that provides output, such as a touch screen, haptics device, or speaker.
Storage 740 can be any suitable device that provides storage, such as an electrical, magnetic, or optical memory, including a RAM, cache, hard drive, or removable storage disk. Communication device 760 can include any suitable device capable of transmitting and receiving signals over a network, such as a network interface chip or device. The components of the computer can be connected in any suitable manner, such as via a physical bus or wirelessly.
Software 750, which can be stored in storage 740 and executed by processor 710, can include, for example, the programming that embodies the functionality of the present disclosure (e.g., as embodied in the devices as described above).
Software 750 can also be stored and/or transported within any non-transitory computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a computer-readable storage medium can be any medium, such as storage 740, that can contain or store programming for use by or in connection with an instruction execution system, apparatus, or device.
Software 750 can also be propagated within any transport medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a transport medium can be any medium that can communicate, propagate, or transport programming for use by or in connection with an instruction execution system, apparatus, or device. The transport readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, or infrared wired or wireless propagation medium.
Device 700 may be connected to a network, which can be any suitable type of interconnected communication system. The network can implement any suitable communications protocol and can be secured by any suitable security protocol. The network can comprise network links of any suitable arrangement that can implement the transmission and reception of network signals, such as wireless network connections, T1 or T3 lines, cable networks, DSL, or telephone lines.
Device 700 can implement any operating system suitable for operating on the network. Software 750 can be written in any suitable programming language, such as C, C++, Java, or Python. In various embodiments, application software embodying the functionality of the present disclosure can be deployed in different configurations, such as in a client/server arrangement or through a Web browser as a Web-based application or Web service, for example.
The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the techniques and their practical applications. Others skilled in the art are thereby enabled to best utilize the techniques and various embodiments with various modifications as are suited to the particular use contemplated.
Although the disclosure and examples have been fully described with reference to the accompanying figures, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the disclosure and examples as defined by the claims.
This application discloses several numerical ranges in the text and figures. The numerical ranges disclosed inherently support any rage or value within the disclosed numerical ranges, including the endpoints, even though a precise range limitation is not stated verbatim in the specification because this disclosure can be practiced throughout the disclosed numerical ranges.
The above description is presented to enable a person skilled in the art to make and use the disclosure and is provided in the context of a particular application and its requirements. Various modifications to the preferred embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the disclosure. Thus, this disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. Finally, the entire disclosure of the patents and publications referred in this application are hereby incorporated herein by reference.
