SOC Audit Failure: Common Audit Mistakes to Avoid

In my experience performing SOC 1 and SOC 2 audits for Linford & Co., I’ve noted the majority of organizations are prepared for audits and able to offer reasonable assurance they met the SOC criteria and their control requirements. But in my conversations with clients, particularly those going through an audit for the first time, there are common fears about what mistakes could lead them to a SOC audit failure. The questions I’m routinely asked sound something like:

• “Why do audits fail?”
• “How do you fail an audit?”
• “How can audit failure be avoided?”
• “What are common audit issues and how do you solve them?”

Audit mistakes can qualify a report, create exceptions and/or create a less secure environment, leaving your organization susceptible to external attacks. While not exhaustive, the list below describes common audit problems and recommendations for mitigating against them. It’s important to remember that every environment is different, and what works for one organization may not work for others, so it’s always recommended to engage your auditor early and often.

Lack of Stakeholder Buy-In

Setting the right tone at the top is critical to a successful SOC 1 or SOC 2 audit. Most people perceive audit activities as a nuisance that interfere with their day to day responsibilities. It’s important for management to quantify the strategic value of obtaining a SOC 1 or SOC 2 report and communicate its value throughout the organization. Understanding that a SOC 1 or SOC 2 report can be instrumental in closing contracts or increasing business with existing clients and identifying it as a strategic objective will cultivate commitment throughout the organization.

Additionally, linking the SOC audit to sales targets engages teams with direct client interaction. These teams can identify ways to use the SOC report as a competitive advantage and increase its value by highlighting the security practices your clients are asking about, such as vulnerability scanning, penetration testing, threat modeling, secure coding practices, data loss prevention, privacy policies, etc.

 

Insufficient Communication and Education

Employees can’t support the SOC 1 / SOC 2 process without understanding what the audit entails. Communication and education throughout the organization is crucial to maintaining an effective control environment. Policies and procedures outlining standards of conduct should be made readily available to staff, and an ongoing training and awareness program should be implemented.

If an organization does not follow the defined policies and processes, it can result in a less secure system, qualified report or even a data breach. A single person not following the process can cause major damage. For example, if employees are restricted from downloading software from the internet, but one rogue administrator downloads malware and installs it on a server, the organization’s security could be compromised.

Educating staff about the purpose and benefits of policies and obtaining their commitment to comply are essential for achieving and maintaining SOC compliance.

Poor Scoping of the SOC 1 / SOC 2 Report

One of the first steps in the SOC reporting process is to define scope. If your organization specializes in one service, this can be straightforward, but what if you offer many different services? If an organization does not properly identify all the risks related to the services provided and design adequate mitigating controls, they could end up being deficient in certain areas. It could result in significant costs to the company in terms of time and resources to enhance or add controls that are not required. Clients may not accept a report if it’s not properly scoped, which could lead to reputational damage or loss of business.

Understanding a service’s scope and boundaries starts with identifying the people, processes and technology that support the service. The next step is to identify the risks that may threaten the achievement of objectives for the identified service(s) and design controls to mitigate against the identified risks.

You will also need to identify what type of report is most appropriate if a customer or auditor has not already specified a requirement. SOC 1 reports are for internal controls over financial reporting, and a SOC 2 report includes controls related to security, confidentiality, processing integrity, availability and privacy. For additional information on what report you may need, see: Need A SOC Report? How To Know Which One Is Best For Your Service Organization.

 

Failing to Perform a Pre-Audit Readiness Assessment

Many audit failures can be avoided by conducting a pre-audit readiness assessment. Ideally, this is done by the firm that will be conducting the SOC 1 or SOC 2 audit. An internal assessment is also a good check to see how prepared your organization is to achieve the required audit criteria.

The readiness assessment should be viewed as a “trial audit” where the required policies, procedures, and control evidence are obtained and thoroughly reviewed just as they would be in the actual audit. The goal is to identify potential control gaps and failures so your organization has an opportunity to correct them in advance of the audit. This can also be a good opportunity to ensure your scoping is appropriate.

Significant Control Failures

If you’ve done your homework and, ideally, conducted a pre-audit readiness assessment, you will have a reasonable level of confidence that you can pass your SOC 1 or SOC 2 audit. However, things can still fall through the cracks and create control exceptions, particularly when your audit is over a period of 6-12 months.

It’s important to understand there are varying degrees of exceptions, and before your audit, you want to make sure you’ve addressed the highest risk areas in order to avoid significant control failures that could result in a qualified or adverse opinion.

For more information on the levels of control exceptions see https://linfordco.com/blog/testing-audit-exceptions/ . For more information on the different report opinions see https://linfordco.com/blog/qualified-auditor-report/.

Control areas most prone to causing significant audit failures include:

• Inappropriate Access Controls and Permissions. Ensuring your users have appropriate access to your products/applications and the supporting infrastructure is crucial in a SOC 1 or SOC 2 audit. The more powerful the access, the greater the audit failure if you don’t get it right. You will want to make sure your onboarding process includes steps to provision access commensurate with the user’s role. Your offboarding process should include steps to remove all access in a timely manner. You should also have processes for adjusting access permissions when users change roles, and perform periodic monitoring throughout the year to detect any issues before your auditor does. Documentation of these activities should be maintained for the audit, and don’t forget to include contractors in these processes if they’ll be getting access to your systems!

• Poor or Nonexistent Asset Inventory Management. Accurate asset inventory management is fundamental to maintaining a secure system and being able to obtain and maintain compliance. If an organization doesn’t know what’s on their network, how can they ensure everything is monitored and patched? Rogue machines are common, and most frequently occur when the asset management lifecycle breaks down. For example, a machine marked for decommission continues to be active on your network, or a Bring Your Own Device (BYOD) policy means devices are coming on and off your network all the time. A single rogue device can be the downfall of even the most secure system. Maintaining an accurate inventory of assets requires both technical and manual processes and procedures, but the key to success is diligent and frequent monitoring. Procure an inventory management product/tool that works for your organization and establish a process to maintain it. An organization can spend a lot of time and money implementing a commercial product, but if it’s not maintained, all that time and money is for nothing.

• Unknown External Communications. Knowing and understanding the organization’s external communications is key to securing the system and obtaining and maintaining compliance. External communications interface with vendors, third-party tools, etc. and are usually the primary methods of contact with the organization’s customer base. Having insecure or unknown external communications greatly increases an organization’s risk of a security incident or data breach. In 2015, the POODLE attack made SSLv3 obsolete and insecure. In 2018, TLS 1.0 and TLS 1.1 were identified as weak protocols; as of 1/31/20, Qualys SSL Labs officially downgraded servers supporting the legacy protocols to a “B.”The industry has made strong efforts to move away from TLS 1.0 and TLS 1.1. However, absent an external vulnerability scan or well-documented interface documents, organizations may be unaware they’re using an insecure protocol. Performing internal and external vulnerability scans and/or penetration tests is a great way to determine the security of your external connections and network configuration, in addition to progressing security threat modeling processes.

• No Separation of Duties. Separation of duties (also referred to as segregation of duties) means that in order to complete a process, more than one person is required. In systems, this is especially important when it comes to Change Management, as you don’t want the same person building, testing and pushing updates to production. If only one person can do everything, it creates an environment where a coding error or more nefarious acts like installing a backdoor to the system can be pushed to production without detection. In larger organizations, separation of duties is overcome by adding more resources, but it becomes a bit more difficult in a smaller organization where there are limited resources with the required coding skillset. Implementing system enforced requirements for peer reviews and/or alerting when code is migrated to production can mitigate common Change Management risks.

Lack of Internal Control Monitoring

If you don’t think about your audit or controls until the auditors come knocking on your door, you may be at a greater risk for audit failures, particularly as you move to a Type II SOC audit. Both manual and automated controls are prone to breakdown, as events like employee turnover or changes to systems and configurations can adversely impact your controls. To safeguard against this, procedures should be established to periodically monitor and confirm the status of controls.

Control owners should be identified and a centralized resource or team should be tasked with gathering data on control status. As data is gathered, any identified breakdowns or changes in controls should be escalated to management and resolved prior to your next audit. Even if a breakdown leads to a control exception in your report, the magnitude of severity to your audit and to the security of your environment will likely be reduced if caught early and remediated timely.

No Subservice Organization Monitoring

In a previous post, Newel Linford stated: “Subservice organizations perform at least some function of the service organizations’ outsourcing activities. If the subservice organizations perform functions that are relevant to the user organizations, then the user organization needs to verify that the subservice is fulfilling their obligations.”

Many times, user organizations don’t review whether their critical subservice organizations are meeting their controls. This may lead to a control not being covered at all. For example, your hosting provider may be responsible for conducting monthly vulnerability scans of your infrastructure, but recommend that you, as a user organization, review the reports and approve their recommended remediation strategy. Both organizations must work together to fulfill their obligations around vulnerability management.

A user organization should review and monitor their subservice organizations to ensure that they are fulfilling their obligations, as well as to understand what responsibilities fall to the user organization to fulfill.

Summary

Whether you are preparing for your first SOC 1 or SOC 2 audit, or have been through an audit before, the above common audit mistakes can sneak up on any organization and each one could qualify a report, create exceptions, and/or create a less secure environment. Stay diligent, know your environment and monitor changes. With proper processes and team buy-in, your SOC audit can be smooth and free of issues.

If you would like to discuss SOC audits more in depth, please review our SOC 1 and SOC 2 audit pages and contact us so that we can help your organization or business with your auditing needs.