Does Your Block Need a SOC?

The role of third-party assurance for blockchains and digital assets

INTRODUCTION

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.¹

Service organizations have long relied on SOC (and preceding audit standards) to deliver assurance to their customers and customers’ auditors. In recent years, SOC ⁱⁱ (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 ⁱⁱⁱ 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?

What Is a SOC Audit Report?

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.

SOC AUDIT FROM 30,000 FEET

SOC 1 – A report on internal controls at a service organization relevant to financial reporting (customer’s financial reporting).

SOC 2 – A report on internal controls at a service organization relevant to Security and Availability, Confidentiality, Processing Integrity, or Privacy (“Trust Services Principles/Criteria”).

SOC 3 – Public distribution version of a SOC 2.

SOC reports present the Independent Service Auditor’s opinion regarding the accuracy and completeness of management’s description of the system or service as well as the suitability of the design and operating effectiveness of controls to achieve the specified control objectives.
SOC reports are a key mechanism for a third party assurance for service organizations.

SOC 2 FROM 30,000 FEET

The 2017 SOC 2 Criteria require the Security principle, at a minimum. Service organizations can choose to add relevant additional criteria (Availability, Confidentiality, Processing Integrity or Privacy), as needed.

SOC 1 & 2 IN A DISTRIBUTED LEDGER AND DAPP WORLD

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 (ICOs^vii 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.

BEYOND SOC: OTHER STANDARDS AND VEHICLES FOR THIRD-PARTY ASSURANCE

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.

RISKY BUSINESS

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.

CONCLUSION

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.

Download White Paper

REFERENCES

Yes, SOC and similar controls auditing engagements have been commoditized. This author will tell it like it is. However, not all SOCs are created equal. When you go to market for a SOC audit, you will see the two extremes: “one-man shops” offering bargain fees, and Big Four audit firms charging a premium for their brand. Bargain SOC reports are worth what you pay for them; they don’t hold sway with procurement folks, and may even attract extra scrutiny from your customers and their auditors. On the flip side, a reputable name on your SOC report is important, and worth paying for. Many firms in the top 25 qualify as more than “reputable.” However, the key is a firm that has referenceable clients and a demonstrated track record in providing these types of attestations. The best audit partner is one that can demonstrate how they offer value outside the testing of controls.
SOC 1® Engagements
AT-C section 320, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting
The AICPA Guide Service Organizations: Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting (SOC 1®)
SOC 2® Engagements
AT-C section 205, Examination Engagements (AICPA, Professional Standards)
The AICPA Guide (SOC 2®) Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy
SOC 3® Engagements
AT-C section 205, Examination Engagements
Why? Because public blockchains are “trustless” and don’t require transacting parties or nodes to have a personal or business relationship built on traditional notions of trust, like handshakes, contracts, audits and the threat of being sued.
In addition to SOC 1 and SOC 2 reports, service organizations that have a SOC 2 can have their auditor prepare a SOC 3 report for distribution to the public (not only to a restricted set of intended users like SOC 2). The AICPA has also released a framework for reporting on “SOC for Cybersecurity,” and has a draft reporting standard underway for “SOC for Supply Chain.”
“Security” — a term so important, but with so many meanings, it is meaningless without explanation or context. The AICPA defines a service organization’s “Security” as a set of nine “common criteria.” In the latest version of the SOC 2 standard, those criteria cover Control Environment (think: organization and management, board oversight, etc.); Communication & Information (think: the controls around how the organization communicates relevant information internally and externally to allow all parties to carry out their specified duties); Risk Assessment (think: a robust process around management’s identification of, assessment of, and remediation of entity-level and technical risks); Monitoring Activities (think: controls that management has in place to receive quality information on the performance of internal control activities, and controls to take corrective action in a timely manner); and Control Activities (this is where you will find the requirements that most people colloquially associate with “security” — logical access, physical access, change management and system operations controls).
The term “dApp” is simply an abbreviation for “decentralized application.” Apps run on centralized servers, but dApps run on decentralized networks of servers or nodes (blockchains).
Initial coin offerings (ICOs) — Generally, a blockchain project (startup group of developers, sometimes without even a basic corporate structure) collecting cryptocurrency of one type (typically BTC or ETH, which have a more stable or proven value) in exchange for the project’s token (which the ICO investor hopes will “moon,” of course — see note below).
Moon lambo — The retail investor hopes the token they bought for pennies or less will shoot to the moon, letting them cash out and buy a Lambo (Lamborghini supercar).
“Off-chain assets” are those that sit in the real world, not connected to or residing on a blockchain. There are examples in the market today of tokens collateralized by baskets of other tokens; because these digital assets reside “on chain,” the need for independent validation is, theoretically, reduced or eliminated.
Controls are defined and repeatable processes, executed by people or technology, that reduce or mitigate a specified risk.
mart contracts can be understood as “if-then-else” statements. IF a certain instruction is received, THEN the smart contract carries out a specified action, ELSE (if the instruction is not received) the program does nothing (or some other specified action). Simple smart contracts are used in many public blockchain ICOs, where ether coins (Ethereum Network) are sent to a smart contract address, which in turn sends a given number of tokens (ERC-20 tokens) back to the sender’s address.
“Sharding” or “Shamir’s Secret Sharing” is an algorithm in cryptography created by Adi Shamir. It is a form of secret sharing, where a secret is divided into parts, giving each participant their own unique part. To reconstruct the original secret (or cryptographic key), a minimum number of parts is required. Sharding keys can create a segregation-of-duties control in the same way a safety deposit box can be secured with two or more keys necessary to open it.