Over the last few years, there has been a proliferation of SOC 2 audit and compliance tools coming to market. The companies providing the tools are promising to help clients prepare for and complete audits in record time. There is venture capital interest in the tools as well, with 200+ million in backing to date. Some of the tool providers are also offering affiliated audit firms or “bundled audits” that perform the audit using the tool and offer low-cost audit reports.
Until relatively recently, the American Institute of Certified Public Accountants, which provides the audit guidance used by CPA firms to perform SOC 2 audits, had not provided much guidance on how SOC 2 automation tools may be used to perform SOC 2 audits. On June 30, 2021, the AICPA did issue a FAQ on the use of FAQ use of SOC 2 Software Tools software tools to perform SOC 2 examinations. This article will summarize the FAQ and risks and benefits of using tools to facilitate SOC 2 audits.
SOC 2 Tools Can Benefit Companies Going Through SOC 2 as Well as Auditors Performing SOC 2s
Auditors have historically gathered audit evidence, the documentation used to support the performance of controls, in a manual way. Some examples of manual evidence collection include onsite discussions with the client, requesting samples of controls’ performance, or taking screenshots of system configurations using screen shares. SOC 2 tools are attempting to change the historical status quo of how auditors perform audits by enabling auditors to access system configurations within clients’ systems without interfacing with the client.
The tools also support the performance of certain manual controls like employee onboarding tasks (e.g., background check, policy acceptance) by reminding clients of the tasks that need to be completed and allowing auditors to pull the task completion evidence directly from the SOC 2 automation tool. If used properly, the tools can help companies preparing for and undergoing SOC 2 audits and the audit firms performing the audits. The past concept of auditors sitting onsite at a client site for weeks at a time and manually collecting all evidence for a SOC 2 is becoming increasingly outdated. This all sounds great, but what are the risks associated with the use of SOC 2 automation tools?
Benefits of SOC 2 Tools Depend on Integrations with Key Systems
SOC 2 automation tools are only as good as the systems they are integrated with. The automation tool integrations are linked to client systems through the use of APIs. Each system that the tools integrate with provides different data via APIs. It is important for the auditor using a SOC 2 tool to understand what data is provided by each system integration and whether the integration and data pulled from source systems are working as intended. If a connection breaks, the data represented in the tool could be outdated, and the auditor could place reliance on outdated information.
What Are the Risks Arising from the Use of SOC 2 Automation Tools?
If the tool is not integrated with the systems in scope for the audit, the auditor could be reviewing evidence for the wrong systems.
Management places over-reliance on the tool and assumes the tool can do more than it actually can. For example, we have seen clients purchase an automation tool because they know they need a SOC 2, but they don’t dedicate the time to tune the tool properly or remediate gaps identified by the tool. Tools can’t remediate controls for clients – clients still need to do that. The tools can represent controls’ operation if they are tuned properly and are representing the in-scope systems for the audit, but purchasing a tool does not allow companies to pass an audit without additional work.
Policies and procedures provided in the tool may not address the risk of the services provided by each client. For example, if a client is in a unique industry, with a unique set of risks (e.g. regulatory or financial risks), a templated policy may not include the appropriate controls to mitigate the unique risks of the client. Another example is that some of the tools facilitate client risk assessments using a set of predefined questions. A client could be in a unique industry, with unique risks, and the pre-defined risk assessment does not address the unique risks. In that case, a company could believe they have identified all relevant risks, but significant risks could remain undiscovered or addressed.
CPA Firms Still Need to Follow SOC 2 Guidance
Regardless of whether an audit firm uses a SOC 2 automation tool to perform an audit or not, AICPA guidance on performing SOC 2 audits still needs to be followed. That means the same standards for evidence collection, independence, and objectivity are required when auditing using a SOC 2 automation tool. CPA firms cannot simply download a SOC 2 report from a SOC 2 automation tool for a particular client and issue the report. Due diligence must be performed to validate the data coming from the tool. This might include going to the source system in some cases when the control is higher risk.
For instance, consider that at least one SOC 2 automation tool has created an auditor portal where certain .CSV reports of system access are bucketed for the auditor. If the auditor doesn’t understand the parameters associated with the generation of the .CSV report, they should not place reliance on the report. .CSV reports are also able to be easily modified. How can the auditor know the report wasn’t modified after it was generated?
Independence Requirements
One of the AICPA’s requirements for CPA firms is that they must maintain independence. The AICPA defines independence as:
“Independence of mind is the state of mind that permits a member to perform an attest service without being affected by influences that compromise professional judgment, thereby allowing an individual to act with integrity and exercise objectivity and professional skepticism.
Independence in appearance is the avoidance of circumstances that would cause a reasonable and informed third party, who has knowledge of all relevant information, including safeguards applied, to reasonably conclude that the integrity, objectivity or professional skepticism of a firm or member of the attest engagement team is compromised.”
In other words, the AICPA requires CPA firms performing SOC 2 audits to be independent of all external parties, including SOC 2 automation tool companies. Moreover, the SOC 2 automation tool company cannot also perform the SOC 2 audit. The reason auditors must maintain independence is they are required to objectively evaluate the controls of clients. If auditors are affiliated with their clients or other parties, independence can be impaired and the auditor may be more likely to overlook control issues and render positive opinions when they are unwarranted.
For example, let’s say a SOC 2 automation tool has an arm of the company that performs SOC 2 audits. This does not pass the independence in appearance requirement by the CPA in this auditor’s opinion. If the audit firm affiliated with the SOC 2 automation tool finds an issue with the way the tool is working, would they be likely to share that information with their client or would they protect their own company? Might the affiliated auditor also place overreliance on the affiliated tool since their paycheck comes from the same company? Questions such as that are what causes a failure in independence in appearance at a minimum.
Summary
In summary, SOC 2 automation tools can be valuable for both companies undergoing SOC 2s as well as audit firms performing SOC 2s, provided both parties understand the SOC 2 guidance and risks of using such tools. Currently, the AICPA has put out only one whitepaper with FAQs that describe risks associated with the use of tools. In the future, the AICPA may come out with more formal guidance for the use of tools, including standards for validating the tools and placing greater reliance on them. In the meantime, it’s still a bit of the wild west when it comes to both the tool providers and the auditors using the tools to perform the audits.
If you have any additional questions regarding the use of SOC 2 automation tools or are interested in attaining the audit services of Linford & Co, please don’t hesitate to contact us.
Rob started with Linford & Co., LLP in 2011 and leads the HITRUST practice as well as performs SOC examinations and HIPAA assessments. He has spoken at Data Center World on compliance-related topics and has completed over 200 SOC examinations. He started his career as an IT auditor in 2003 with PwC in the Systems and Process Assurance group, and has worked in a variety of industries in internal audit as well as for the City and County of Denver.