I always thought that there were very few sources talking about the reasons why would anyone need SOC 1 reports. So, in this post, I wanted to try to explain why SOC 1 reports are supposed to make our lives easier, even though it seems like they only complicate everything:)
A BRIEF OVERVIEW OF RELEVANT SOX REQUIREMENTS
Public companies are required to have systems, procedures, and controls in place to ensure that the financial information they report is not materially misstated. This requires a deep understanding of each step involved in the processing transaction classes that are material for the company. When the externally reported, financial information is prepared using third-party software, management wants to be able to rely on the functionality of the product they paid for. In practice, the internal team would have to first perform due diligence to ensure that the software product actually works as expected and produces accurate results. Once the reliability is established, it is reasonable to believe that automated processes are less exposed to the risk of human error and this company would not need to do extensive work to validate the data generated by the product.
However, to place reliance on the software with the code base controlled by an external party, it is necessary to also be certain that any post-implementation changes to the source code are appropriate. This is because malicious or inappropriate changes in the code may cause potentially material misstatements due to data loss or corruption. The output data produced by this software will no longer be reliable. But how can accountants possibly address it if the code is controlled by a third-party developer? This is where SOC 1 reports come into play.
SOC REPORTS AND HOW ACCOUNTANTS CAN USE THEM
Assume that one of the software vendors of a public company does not have a clean SOC report. Management cannot rely on the vendor's processes and controls over the design of this software product. Now in order to rely solely on software outputs, management would have to do additional work to validate the information generated by the product. This additional work may include - reconciling the inputs in the system to external sources, recalculating numbers produced by the software, developing an estimate of the outputs based on the independent data sources, and concluding on the reported information reasonableness based on the fact that this estimate is sufficiently precise, and deviation of actual amount is immaterial.
When organizations outsource internal processes to an external vendor, they expect that information received from vendors will be complete, accurate, and ready to be ingested by the financial reporting function. Management expectations are that vendors of outsourced processes should address all related compliance requirements because this is what service vendors are getting paid for. SOX does not relieve companies from the responsibility to maintain internal controls over information produced externally. However, companies that outsource significant functions are inherently limited in their ability to manage outsourced operations. To address these limitations, service vendors implement internal controls to satisfy compliance requirements that apply to their customers and undergo service organization audits to provide customer management teams with the comfort that appropriate controls are in place and operate effectively. This way customers can prove that they have met SOX compliance requirements by referencing the results of the service organization audit.
DIFFERENT TYPES OF SOC REPORTS
There are three categories of SOC reports. SOC 1 reports provide comfort about internal controls over financial reporting. SOC 2 and 3 reports provide assurance over additional third-party risks outside of financial reporting (e.g., security, confidentiality, privacy). There are also two types of SOC reports for each category. Type 1 reports address only the design and implementation of controls. Type 2 reports provide an extended level of assurance that includes the operating effectiveness of internal controls identified.
SOC 1 reports are not required for custom software packages where both the underlying code and its execution are fully controlled by the entity (which rarely happens in practice because almost any software packages have external dependencies not hosted, managed, maintained, or updated by the entity's IT personnel). However, SOC 1 reports will be necessary for external dependencies of in-house solutions and any cloud-based systems that participate in the flow of information that is used for financial reporting purposes.
Today we only talk about IT systems/software packages that affect the entity's flow of information and ultimately have an impact on the information reported externally. Considering this, we can say that the completeness and accuracy of the entity's data may be compromised whenever data in the IT system is:
entered or loaded.
stored, accessed, or retrieved.
summarized or accumulated.
subjected to calculations.
HOW DOES THIS APPLY TO BLOCKCHAIN?
Each blockchain ledger is an independent IT system and its reliability depends on algorithms and implementations used to create each individual blockchain. It is important to remember that differences in consensus mechanisms and other architectural elements of each individual blockchain may theoretically compromise the integrity of ledger data. It is fair to dismiss the risk that the integrity of data within blockchain ledgers themselves has been compromised. This is because the underlying technology by design ensures the integrity of ledger data. However, it would not be unreasonable to expect that one of the altcoin blockchains was developed using a brand-new consensus mechanism that compromises the integrity of data stored on this specific blockchain. It is necessary to determine on a case-by-case basis whether the underlying technology elevates the quality of data stored on each blockchain to the level that allows us to use this data as a source of truth. In a remotely possible scenario when data on blockchain may be compromised, auditors and management would have to create a way of validating on-chain data against its source - an external party that the entity has transacted with (unless we can point to a SOC 1 report showing that these controls has been already designed, implemented, and operated effectively).
WHY DO BLOCKCHAIN EXPLORERS NEED SOC 1 REPORTS AND WHAT TO DO IF THEY DON'T HAVE ONE?
Blockchain data is not directly exposed to the external world. Any on-chain data needs to be extracted from the system before it can be discovered by external users. The completeness and accuracy of data stored on-chain itself may be compromised during data extraction, hence, adequate controls are necessary to address this risk. Typically, data is extracted using block-explorers. When these applications are developed by a reporting entity, the related general IT risks are addressed by access and change management controls that are already a part of the entity's own IT environment. But this works only if this underlying code is fully controlled by the entity. Hence, if external vendors have control over future changes to the code, separate control activities are required. These activities may include a recurring review with manual identification of any changes in the underlying code, or other automated tests performed by the company's IT team.