Common SOC Report Exceptions and How To Mitigate Them

When organizations hear they may have an exception in their SOC report, the first response might be to panic or assume the worst. SOC report exceptions are much more common than many people realize, and there are ways to reduce the likelihood of exceptions or prevent them from occurring in the future. We sat down with Katie Bialy, senior consultant with BARR’s Cyber Risk Advisory practice, to discuss common SOC report exceptions and what they mean.

What is an exception in a SOC report?

An exception in a SOC report is an instance in which there is a deficiency in the design or operating effectiveness of a control—essentially, a control isn’t working the way it should. There are three different types of exceptions that can happen in a SOC report. Let’s take a closer look at the types of exceptions and some examples of each that Bialy has seen.

System description misstatements: A misstatement is an error in how an organization describes its systems.

“An example of a misstatement would be if an organization claimed that all employees undergo security awareness training, but it’s not actually required,” Bialy explained. “This type of exception is rare. I’ve never seen this happen with any clients I’ve worked with.”

Deficiency in the design of the control: This is when a control is ineffective because it wasn’t properly designed.

Bialy gave the following example for this type of exception: “If an organization has a control that a vendor risk assessment is performed by looking at the vendor’s attestation reports but the actual process to perform the assessment only involves looking at vendor websites, this would be a deficiency in the design of the control.”

“I’ve not commonly seen this type of exception because BARR works with our clients to ensure their controls are designed properly during the readiness assessment phase,” said Bialy.

Deficiency in the operating effectiveness of a control: This is when a control doesn’t operate properly as intended or as expected.

“For example, if you have a control in place that terminates user access to in-scope systems within one business day of termination date, and one of the users selected by your auditor has access removed to an in-scope system one week after their termination date, this would be an exception,” provided Bialy. “This is the most common type of exception that I see in my role.”

How common is it for a SOC report to list exceptions?

According to Bialy, it’s not uncommon for a SOC report to have exceptions, particularly with companies in their early stages that are growing rapidly or have less mature cybersecurity programs. That said, even companies with mature cybersecurity programs and environments that remain the same year over year may find themselves with an exception in their SOC report, particularly if the report is covering a one year period of time. Bialy provided the following example of a potential scenario with security awareness training:

“If you’re a company of 500 people with a control in place that every user has undergone security training, and BARR tested a sample (in other words, a group of employees), and a single employee hadn’t undergone that security training, then this would be called out as an exception in the report,” Bialy explained. “It can be easy for one employee to be overlooked at larger organizations, especially if the company doesn’t have a tool in place to track compliance.”

How do exceptions impact an auditor’s opinion?

Bialy has a typical process for handling exceptions and potential exceptions when they come up.

“If I find some evidence during my testing that looks as if a control is not designed properly or operating effectively, I ask the client about the issue. It’s often that the client has an explanation for the issue once I bring it up,” Bialy said.

“For example, I once worked with a client that was using an automation tool to track their vulnerabilities, and the tool showed that some of the vulnerabilities were not resolved during the audit testing period. Once I brought it up with the client, they let me know the automation tool wasn’t properly tagging the severity level of the vulnerabilities. I helped the client make a process improvement to tag the vulnerabilities appropriately, and this issue ended up not becoming an exception on their report.”

In other cases, a client confirms that the control is not designed properly or operating effectively. In these instances, Bialy typically discusses her findings with the internal team at BARR to determine the impact on the criteria or objectives that the control helps meet. From there, the BARR team is able to determine how the exception will impact the client’s report.

Whether or not an exception impacts the opinion of the report depends on the number of exceptions, their scope, and severity. The opinion will be listed in Section 1 of the SOC report, and there are four possible ways the auditor may present an opinion:

Unqualified: This opinion indicates the author did not find any material issues during the audit—the opinion BARR clients strive for.
Qualified: This opinion indicates the auditor found material issues during the audit, but the scope of the issues is limited. “Exceptions that result in criteria not being met could result in a qualified opinion,” Bialy explained.
Adverse: This opinion means that the auditor believes there are material and pervasive issues, and the report reader should not rely on the vendor’s system. “For example, an adverse opinion might mean there are issues not just around change management but also with logical access and risk management,” said Bialy.
Disclaimer: This result means that an auditor is unable to express an opinion due to insufficient evidence.

These four opinions—especially the adverse and disclaimer opinions—shouldn’t scare organizations beginning the audit process. “In my time as an auditor, I’ve never seen an adverse or disclaimer opinion,” said Bialy.

How can organizations use automation tools to prevent exceptions?

Utilizing automation tools and other monitoring or alarming mechanisms can help organizations ensure they are remaining SOC compliant throughout their audit period, helping to reduce exceptions.

“For example, if you have a tool that alerts you when it’s time to do your annual policy review and approval, you’re much more likely to stay compliant than if you just try to remember yourself with a mental note,” said Bialy.

What should an organization do when they have exceptions in their SOC report?

An organization can use exceptions as an opportunity for improvement. Working with a cybersecurity partner like BARR can help the organization understand and address the exception so that it can be resolved.

Exceptions are listed in Section 4 of the SOC report, along with all controls that were tested. Exceptions are also listed in Section 5 of the report, where organizations have the ability to respond to each of the exceptions with an explanation of how the exception was handled.

“BARR highly recommends our clients resolve exceptions within the audit period so they’re able to talk about the remediation and management response to the exception in Section 5 of the report,” said Bialy.

It’s not uncommon for exceptions to happen, but by utilizing automation, monitoring compliance, and working with a trusted cybersecurity advisor, organizations can manage exceptions and reduce the likelihood of exceptions in the future.