DOES YOUR BLOCK NEED A SOC? (Part 1)
A casual, but informative read for technical and non-technical executives on the role of third-party assurance over blockchains and other things crypto.
I. A Three-Part Series
In March of this year, I wrote and published a whitepaper on the role of third-party assurance in a blockchain world. This three-part series will expand on the topic with an aim to demystify SOC reporting and provide execs and founders useful guidance on whether their block needs a SOC.
I have been working with clients in blockchain, digital assets and third-party assurance reporting since early 2016. Over those years, I have managed a high volume of SOC clients and helped over 250 clients achieve their first SOC report or expand current programs to cover industry-specific needs. Serving both large, publicly-traded service organizations, with complex operations and legacy systems, and also startup companies, with unique needs, I have audited a wide array of control environments and risk landscapes. I am passionate about client service, advising on efficient and effective ways to achieve desired third-party assurance goals, and keeping clients abreast of best practices. In early 2016, I had the opportunity to apply this passion, to a great curiosity of mine… crypto currency. After the internal controls work for a large (now one of the largest) VCEs, I was hooked.
In early 2017, I advised one of Armanino’s early blockchain clients through their first SOC 2 report (which, as far as a I know, was also the first ever SOC 2 audit opinion over a blockchain product/service). This particular SOC 2 engagement illuminated the fact that there are many traditional best practices and controls that are still relevant to blockchain and digital assets ecosystems, and also many more risks and associated controls that are unique. This three-part series will speak to some of those unique risks and controls.
TLDR: Part I will cover an introduction to SOC reporting. This intro should be useful for early-stage companies, whether their business model involves blockchain or not. Part II will apply SOC and third-party assurance concepts to blockchain and digital assets use cases.
Lastly, in Part III we will go beyond SOC and take a look at other third-party assurance mechanisms that are highly relevant to blockchain and digital assets use cases.
II. 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 over 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 over key aspects of outsourced functions, SOC audit 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 has the potential to reduce the need for third party assurance ³ , in some use cases, but also the potential to 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? In either case, the question remains. Does your block need a SOC?
A. What is a SOC Audit Report?
SOC actually stands for “System and Organization Controls” (recently updated from its prior meaning, “Service Organization Controls”). There are two main types of SOC audit reports – “SOC 1” and “SOC 2.” To keep it simple, remember that SOC 1 is a report that has to do with money (cha-ching) or outsourced transaction processing of some sort. And remember that SOC 2 is focused on security. Both types of SOC reports are governed by strict attestation standards issued by the American Institute of Public Accountants (AICPA). They can only be issued by Certified Public Accounting firms, and they can only be distributed to a limited set of “intended users.” That’s it, in a nutshell; there is a more technical description herein if needed.
In addition to SOC 1 and SOC 2, service organizations who 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 American Institute of Certified Public Accountants (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 that is 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 very 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, technology and control failure 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);
- “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 2017 SOC 2 Criteria require the “Security” principle, at a minimum. Remember “Security” as the plate to the buffet; you need it as the base to add the other dishes you may desire. Service organizations can choose to add relevant additional criteria (Availability, Confidentiality, Processing Integrity, and Privacy) as needed.
Management Tip: When considering what criteria are applicable to your business and operations, it is advisable to listen to your customers and prospects as to what they find valuable. However, I also caution clients to be proactive in communicating to their customers and prospects which criteria are actually applicable, and which are not applicable, to their business and operations. Sad to say, but procurement folks, event at leading tech companies often ask for a SOC report (or coverage of other industry-specific frameworks) that simply do not apply ⁴, or do not make sense given the nature of your product and service offering. Do you have a compliance page on your public website describing what standards apply to you and how your business manages compliance with relevant standards? You should.
B. Do I need both SOC 1 and SOC 2?
Maybe. There are many organizations that maintain SOC 1 and SOC 2 reporting programs. If you are offering a service that involves outsourced transaction processing, and users of your service also rely on your organization to host the system that processes transactions, stores confidential data, or private data of their users, then you may be asked to provide assurance over both the service and the system. Don’t panic. There are clever and efficient ways to maintain SOC 1 and SOC 2 reporting programs. This is a great question to ask your prospective auditor. How would they go about helping you achieve dual reporting, and assist you in efficiently maintaining a program of dual reporting over time?
C. Do I need a “Type I” or a “Type II” Report?
Probably both, but only a Type II in the long-run. To clarify, a “Type I” report is SOC 1 or SOC 2 report that covers a “point in time.”
A “Type II” report is a SOC 1 or SOC 2 report that covers a “period of time.”
More specifically,
· A SOC 2, Type I report provides report readers assurance that, as of a given date, the service organization’s controls were suitably designed, and placed into operation, to provide reasonable assurance that the specified SOC 2 Criteria would be met if those controls operated effectively over time.
· A SOC 2, Type II report provides report readers assurance that, between given date X and given date Y, the service organization’s controls were suitably designed to meet the SOC 2 Criteria, placed into operation, and also operated effectively over the specified time period to provide reasonable assurance that the specified SOC 2 Criteria were met.
An approach that works well for many clients is the stepping stone into SOC reporting — going for the Type I, and then later the Type II.
Management Tip, The Upside: You can receive an audit report in hand sooner than later and the audit itself is a lighter lift because the service auditor will test the design of the controls, not test the effectiveness of controls over time by selecting multiple samples. And, if the service auditor does things correctly, some of the work they do during the Type I can be leveraged down the road for the Type II, making this more efficient on your limited resources and time.
Management Tip, The Downside: The Type I report is ultimately not as valuable to a discerning procurement manager because the report only speaks to a point in time, which has inevitably passed. Thus, Type I reports do a good job showing a startup’s move in the right direction but tend to have a limited shelf life. Lastly, if you intend to complete a Type I and then a Type II three months later, this can cause some audit fatigue on your engineering, info-sec, and product teams.
D. How do I get from point A to point S.O.C.?
If you are building a new business, you are stretched thin. If you are trying to scale up, you are as thin as a crepe. So, getting your SOC audit completed efficiently and at a requisite level of quality will require you to educate your co-founders and department leads on the importance of the process, not just the outcome.
In my experience, management teams that are focused on the result (getting that report in hand) without placing proper emphasis on thoughtfully assessing risk in their business and building the control environment to address those risks have very difficult future reporting cycles. The second round of SOC is difficult for these organizations because they have not taken full ownership of their controls and created sufficient audit trail to demonstrate that the controls are in place and working. Thus, each audit cycle is progressively more painful; the auditor expects a bit more maturity from your environment each year, but the business feels like the requests simply don’t align to their operations.
III. Part 1 Conclusion
So, does your block need a SOC? Read on in Part II to find out.
IV. About the Author, Noah Buxton, Esq., Director, Blockchain, Risk Assurance & Advisory, ArmaninoLLP
Noah has more than 10 years of audit, legal, IT and regulatory compliance experience. Noah is a leader in Armanino’s Blockchain practice. Noah advises blockchain and virtual currency clients on myriad industry-specific issues; his expertise lies in IT & Security matters as well as financial assurance and reporting for Virtual Currency Exchanges, Security Token Issuers, broker-dealers, and blockchain and cryptocurrency startups.
In 2018, Noah worked with leadership to found and formalize Armanino’s Blockchain practice. From 2016 to mid-2019, Noah led a large team of practitioners performing third-party assurance attestations, including System and Organization Controls (SOC 1,2,3), cybersecurity (NIST, SANS, etc.) and HITRUST assessments for startup, mid-market, and large publicly-traded companies.
As of August 2018, Noah also serves as Director of Product for Armanino’s TrustExplorer platform and Armanino’s Blockchain Lab. TrustExplorer is a suit of assurance solutions for stablecoins and blockchain-native businesses and the world’s first real-time system for confirmation of asset backing for asset-backed stablecoin issuers.
Noah is a member of the Information Systems Audit and Control Association (ISACA), the American Institute of Certified Public Accountants (AICPA), the California Bar Association and International Association of Privacy Professionals (IAPP), as well as the Chamber of Digital Commerce (CODC). Noah is a contributing writer and member of the AICPA Blockchain for SOC Working Group, as well as the joint working group of the AICPA and ISACA focusing on controls assurance for blockchain ecosystems. Noah holds certifications for the Linux Foundation’s Hyperledger permissioned blockchain and is a Certified HITRUST CSF Practitioner.
V. Footnotes
(1) Yes. SOC and similar controls auditing engagements have been commoditized. This author will tell it like it is. While these audit services have been commoditized, 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 4” 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 actually 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. There are many firms in the top 25 rank that qualify as more than “reputable.” However, looking for a firm with referenceable clients that has a demonstrated track record in providing these types of attestations is key. The best audit partner will be the one that can demonstrate how they offer value outside the testing of controls.
(2) 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 Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy.
SOC 3® Engagements — AT-C section 205, Examination Engagements
(3) 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.
(4) Example: Is your business in health care technology? If so, you already know about the Federal requirement for healthcare providers and their business associates to comply with the Health Information Portability and Accountability Act’s (HIPAA) Security and Privacy rules. You may have also heard, or been asked about, HITRUST. HITRUST is a Risk Management Framework which provides a standard set of control objectives and controls (as well as multiple implementation levels of each control), for business in the healthcare space. HITRUST as an organization that sells “certification” with their framework, which is actually a framework built on existing frameworks, has done a splendid job convincing carriers to include a requirement that their business associates comply with HITRUST in their service agreements and contracts. This has caused a trickle down of compliance requirements which is often misapplies to heathcare technology companies, and grossly misapplied to service organizations that service a business associate, but do not deal in covered information. Confusion abounds; confusion is costly, so knowing how to “push back” is important. Back to blockchain.
