As adoption of SaaS and cloud applications has grown across industries, there has been a general 1:1 increase in the need for third-party assurance for those systems and outsourced functions. With procurement, legal, information security and third-party vendor management departments (as well as the financial auditors and regulators of enterprise customers) demanding transparency and assurance for key aspects of outsourced functions, SOC auditing and reporting is a hot commodity.1
Service organizations have long relied on SOC (and preceding audit standards) to deliver assurance to their customers and customers’ auditors. In recent years, SOC ii (particularly SOC 2) has gained popularity as a business development tool for young startups to demonstrate the requisite level of control maturity to those skeptical procurement folks. Application of blockchain technologies can reduce the need for third-party assurance iii in some use cases, but can also dramatically increase the need for such assurance services in other use cases.
So, is a SOC audit a necessary tool to provide assurance for your blockchain-based business, or is it just a box to check? Either way, the question remains: Does your block need a SOC?
SOC stands for “system and organization controls” (formerly “service organization controls”). There are two main types of SOC audit reports iv — SOC 1 and SOC 2. To keep it simple, remember that SOC 1 has to do with money (cha-ching) or outsourced transaction processing of some sort. SOC 2 is focused on security.v Both types of SOC reports are governed by strict attestation standards issued by the American Institute of Certified Public Accountants (AICPA). The reports can only be issued by certified public accounting firms, and they can only be distributed to a limited set of “intended users.” We’ll get into more technical details below, but in a nutshell, that’s it.
From Satoshi’s genesis block to the advent of dApps,vi the blockchain and crypto ecosystem places great importance on a few core values: being antiestablishment, peer-to-peer, trustless, and secure and immutable by design. From the witches’ brew of distributed networking, cryptographic algorithms and a trustless consensus protocol, Bitcoin was born. A modern-day gold rush has followed: miners seeking spoils, projects raising eye-popping capital without the venture capital establishment (ICOsvii and STOs), and retail investors seeking 1,000% returns (a.k.a. moon lambo viii).
Nevertheless, the trustless peer-to-peer crypto economy certainly needs trusted advisors, trusted intermediaries and third-party assurance. Yes, there are many scenarios in which the protocol, the hash power of the network, and the underlying cryptographic algorithms provide the trust. But in many instances, SOC (and some other standards mentioned below) are not only appropriate, but essential.
A few such instances are: crypto funds, asset-backed tokens, crypto accounting solutions, private blockchain platforms and permissioned blockchain consortiums, and, of course, custodial wallet providers and exchanges. SOC and third-party assurance are important in each of these use cases.>
CRYPTO FUNDS
For digital assets under management, fund subscribers may demand assurance regarding the business process and IT general controls in place to ensure that investor contributions are properly managed and segregated, accounts are periodically reconciled, investor reporting is complete and accurate, and the IT environment adequately addresses risks presented by improper logical access, physical access, change management, etc.
ASSET-BACKED TOKENS
“Asset-backed tokens” is an umbrella term that covers several different stablecoins and similar crypto creations. Most easily understood are fiat-backed stablecoins, which are tokens issued (“minted”) on a given public blockchain “collateralized” or backed 1:1 by a fiat currency such as the U.S. dollar, British pound, or Japanese yen. The more complex crypto creations are tokens “pegged” to another currency (digital or fiat), pegged to a “basket” of securities or other assets, or collateralized by debt obligations or other financial instruments.
So, in this sometimes murky but dynamic and interesting space, there are a number of places where trusted intermediaries, fiduciaries, oracles and auditors will play a key role. There are too many examples to dive into here, but collateralized tokens provide a good example. Purchasers and holders of tokens collateralized by off-chain ix assets will need third-party assurance on the quality of collateral, the underlying income streams, the risk profiles of collateral, etc.
CRYPTO ACCOUNTING SOLUTIONS
Because all current crypto accounting software offerings are offered as SaaS, assurance on the security and availability of the platform — as well as the controls over the confidential data therein — will be key considerations for “user entities” (SOC speak for “customers”). However, there are also a number of unique considerations for crypto accounting solutions. Most of these offerings have integrations to third-party exchanges and custodial and non-custodial wallets, so the key consideration for customers will be how they can rely on the technology and automated controls that allow blockchain data to be translated and made useable to the application. Another consideration is what (if any) controls ensure that integrations to third-party exchange data deliver reliably complete and accurate data.
If you are offering a crypto accounting solution, the answer is clear. Yes, your block needs a SOC.
PRIVATE BLOCKCHAIN PLATFORMS AND PERMISSIONED BLOCKCHAIN CONSORTIUMS
Permissioned or “private” blockchains have a potent ability to solve many enterprise problems — by increasing the efficiency of supply chains, providing transparency to the provenance of materials used in manufacturing, and offering trusted identity, among other things. Indeed, some of the largest enterprises in the world have experimented with blockchain solutions, and there are multiple successful implementations.
A number of the existing implementations feature a consortium of enterprises, not just a single enterprise. In a blockchain consortium, the need for third-party assurance is relatively clear; SOC 1 and SOC 2 reports are an apt vehicle for additional trust and assurance among a consortium of private blockchain participants. However, the use of SOC reporting to deliver such assurance may require some adaptation of the current standard, or at least a novel approach by the auditor.
Specifically, the SOC 1 and 2 standards rely on a clear demarcation between the service organizations and user entities, where the service organization has taken over an outsourced function for the user entity. Contrast that with a blockchain consortium, where participants have not outsourced a function to their cohorts, but rather changed the way that they trust, transact and record transactions among the members.
Some enterprise blockchain consortiums have one dominant participant (for example, the Walmart supply chain consortium). Others have participants on more equal footing. In the case of a leading or dominant participant, the dominant participant will likely govern access, consensus, change management and other aspects of the blockchain ecosystem. In more equal blockchain consortiums, the issues of governing the ecosystem are likely to be more complex and will likely require trusted intermediaries and auditors.
Examples where auditors and consultants will be trusted intermediaries, perhaps through SOC reporting, include: assurance on the existence and valuation of realworld assets represented on permissioned blockchains; testing consensus mechanisms; correction of improper ledger entries; and settlement controls for private blockchains that use tokens for tracking or payment.
So, does your permissioned block need a SOC? Yes. There are many potential applications of SOC and similar audit examinations to the assurance needs of permissioned blockchain consortiums and their members.
CUSTODIAL WALLET PROVIDERS AND EXCHANGES
Third-party assurance is necessary in custodial environments. Some larger exchanges have recently announced that they have completed their SOC audits, and others that we know are soon to make this announcement. Soon this will be the norm for all centralized exchanges.
Large financial institutions are also getting into “institutional custody solutions,” offering institutional Bitcoin investors the highest available protection over their digital assets.
Does your virtual currency exchange or custody solution need a SOC? If the exchange has a custodial wallet feature, then yes. Providers of “institutional grade” custody solutions will most definitely be asked for SOC 1 and/or SOC 2 reports. Decentralized exchanges are a different animal, of course.
JAPANESE SEGREGATION AND SECURITY AUP
In January 2019, the Japanese Institute of Certified Public Accountants finalized its practical guidance for financial statement audits of virtual currency exchanges. In mid-2018, the Japanese Financial Services Agency (the equivalent of the U.S. SEC) issued an agreed-upon procedures (AUP) framework that all cryptocurrency exchanges operating in Japan had to be audited against to be licensed to operate with the Japanese government
CCSS STANDARD
The CryptoCurrency Security Standard (CCSS) was developed by industry leaders as a standardized mechanism to secure information systems that use cryptocurrencies. The CCSS framework is developed and maintained by the CryptoCurrency Certification Consortium (C4). The C4 states: “By standardizing the security techniques and methodologies used by cryptocurrency systems around the globe, end-users will be able to easily make educated decisions about which products and services to use and with which companies they wish to align.” While the CCSS doesn’t yet have a live certification available, qualified auditors will likely be required to assess and attest before the certification can be issued for a given organization or system.
The CCSS has great appeal, as it is a robust and tailored framework.
OTHER CYBERSECURITY STANDARDS
Existing and prevailing cybersecurity standards like the CCSS will almost certainly play an increasing role in thirdparty assurance on certain blockchain networks. Standards promulgated by the National Institute of Standards and Technology, as well as the SANS Top 20 (from the SysAdmin, Audit, Network and Security Institute), are leading cybersecurity standards that currently inform security at virtual currency exchanges.
No matter how much crypto Kool-Aid you drink, you can’t see blockchain and crypto as risk-free. In the headline-grabbing exchange hacks, general market volatility, known vulnerabilities of smart contracts, and the more pedestrian concerns regarding Proof of Elapsed Time (PoET) and other consensus mechanisms employed by permissioned chains — it is clear, risk abounds. And risk only responds to control.
Based on our experience auditing custodial virtual currency exchanges, private blockchain platforms, and other players in the space, these are the general categories of risk that need to be controlledx for.
SELECTED CATEGORIES OF RISK IN BLOCKCHAIN & CRYPTO
1. Infrastructure Ops, Development Ops, and Information Security: A lack of defined and repeatable processes for managing infrastructure can lead to operating system and network vulnerabilities. Improper development operations (DevOps) can lead to introduction of vulnerable code into a system’s code base. And a lack of an information security program to govern access to (and use of) confidential or sensitive data can lead to information leaks and data breaches. SOC 2 is a reasonable vehicle by which management can implement (and report on) controls over infrastructure, DevOps (application security) and information security.
2. “Smart” Contractxi Vulnerabilities, Misconfiguration or Fraud: Smart contracts — which are actually still “dumb” contracts — are simply if-then-else programs that run on public or private blockchains. Because smart contracts are just computer code, they are subject to inherent vulnerability, misconfiguration vulnerabilities and fraud. Therefore, smart contract auditing by an independent third party may be warranted where auditing of opensource smart contracts by a technically savvy user community is unavailable or unreliable. While SOC 1 and SOC 2 do not directly fit the bill, management of a given blockchain project could implement smart contract audit controls and monitoring. These controls would generally satisfy SOC 2 criteria for “change management,” “monitoring of controls” and “system operations.”
3. Cryptographic Keys: Most crypto scenarios involve public and private cryptographic key pairs. The private keys must be securely generated, stored, operated and ultimately retired. Similarly, cryptographic key management may also play a role in system administration (e.g., SSH keys for access to servers supporting a blockchain or cryptocurrency platform). Insecure generation and improper use, sharing and storage of keys can lead to the loss or theft of digital assets, as well as compromised IT systems. Typical controls include the use of hardware wallets, shardingxii and distribution of keys, robust segregation of duties and hardened technology infrastructure. All of the above would be relevant controls to meet relevant SOC 2 criteria.
4. Consensus Mechanisms and Protocols: Although blockchain technology helps ensure data immutability, the integrity of data depends on approval and consensus mechanisms (e.g., proof of work, proof of stake, PoET) among participants (nodes). If a consortium of independent entities relies on a permissioned blockchain, poor governance may lead to multiple, possibly conflicting blockchain histories that cannot be resolved between participants. Indeed, the consensus mechanisms typically used by permissioned blockchains are less “strict” and can allow for conflicting ledger entries, or later revision of ledger entries. Therefore, the third-party assurance mechanisms and governance in permissioned blockchain scenarios will be an evolving area.
5. Existence, Rights and Obligations: As tokenization of real-world assets, securities and other financial instruments is ramping up, lack of third-party assurance and transparency presents a very high risk that tokens offered and traded will not be backed as stated, that collateral will not be properly escrowed, that collateral backing tokens will have undisclosed encumbrances, or that the valuation of underlying assets will not be reliable.
6. Interoperability and Integration: Use of blockchain technology, or cryptos based on public blockchains, is not isolated from an organization’s existing technology stack. Interoperability is a problem many projects are currently trying to solve. With respect to third-party assurance reporting such as SOC, the focus for management and auditors will be understanding the IT environment and system integrations, and what (if any) automated and manual controls are in place to ensure that data produced from blockchain-connected systems is complete and accurate.
So, does your block need a SOC? If SOC means third-party assurance, then yes, in most cases your block will need a SOC. The takeaway is this: Blockchains and crypto are deeply rooted in a belief that the algorithms provide all the trust needed. But myriad real-world examples, and evolving and theoretical use cases, require human involvement — whether the human acts as an oracle to ensure real-world data comports with data entered onto a blockchain, or as an auditor valuing collateralized income streams for an asset-backed token. The community is beginning to accept the fact that blockchains and cryptos need third-party assurance, offered by human actors.