Co-author: Steve Seideman, Principle Security Consultant at Prescient Assurance

Your type 2 SOC 2 audit is underway and appears to be going well. Your auditor has a stack of evidence to sift through and has held meetings with control owners. When it comes time to review a draft of your SOC 2 report, you notice a ‘test exception’ appears in Section 4. Did you just fail your audit? What happens now? Could you have avoided this? And why are you just learning of the exception now, after weeks of meetings and discussions with the audit team?

What just happened?

In this scenario, you did not fail your audit. It is normal for an auditor to have findings or uncover instances where a control did not perform as intended. Ideally your auditor raises these issues as they occur rather than surprising you when it's too late to do something about it. In this scenario, Section 5 of the SOC 2 report will come into play. This section is where you explain to the reader of your report how you have or will address the finding. More on Section 5 is below.

What exactly is a test exception? 

It is your auditor’s job to test each control that you have identified to address all relevant Trust Services Criteria. Your auditor will inevitably uncover instances where someone once missed a required hiring step, gave a verbal approval instead of a documented one, or performed a control later than scheduled. When findings like these relate to the operation of a control, this is called a test exception. 

Is a test exception the end of the world?

A test exception simply means that the auditor found a discrepancy in how a control (or controls) were either designed or how they are being carried out. It rarely means you failed your audit, but it does mean that you will receive a ‘qualified’ (or less than perfect) audit opinion. The gold standard is an unqualified (or clean) opinion. In fact, many of the largest SaaS providers occasionally have a test exception in a report and the world keeps turning. It takes many test exceptions to ‘fail’ your audit, and rather than issue a dire report your auditor will likely postpone the audit until you are more prepared.

How to discuss exceptions with your auditor

A good auditor will raise their findings with you well before they draft their report, hopefully during their field work. When an auditor presents a possible test exception or other finding, consider the following:

• Do they have all the information possible to validate whether it is an exception, or do they need more evidence or information to make an adequate assessment?
• Are there any compensating controls that should be folded onto the SOC 2 that the auditor could test and include in the report?  
• If this is a known issue, including it in the Risk Assessment process can help give the auditor context about the risk of the control. Low risk issues are much easier to handle than higher risk exceptions.
• It may even be possible to de-scope the control if it does not directly apply to core security controls protecting the system or to the business or system being examined. For example, a penetration test may not be required for a company that has no physical office, and no customer facing applications. Service organizations using Microsoft’s Office 365 may be in this situation.

What to include in Section 5

Section 5 of your SOC 2 report can be used to explain how your organization mitigates or addresses exceptions. You can share your assessment of the risk that the control exceptions poses, any compensating or mitigating controls in place to reduce the risk, as well as any action plans. You can also share this information if the item has already been remediated. Note that if the exception has been remediated between the time it was found and when the SOC 2 report was issued, the auditor cannot retest until the next audit cycle. 

Section 5 information is not assessed by the auditor and does not carry any particular weight with the opinion expressed in the SOC 2 report. However, it does help to provide context and additional information to your clients to help reduce any issues that may come up during a Vendor Risk Management or onboarding process.

Final thoughts

Exceptions do not mean you fail your SOC 2 audit! They just mean you might want to tighten up a process, re-educate a control performer, or even implement a monitoring control. While no one wants to see an exception on a report, they do happen. By addressing them in Section 5, you can give your reader comfort that you take the exception seriously and have a well thought out plan to address them. 

Prescient Assurance is a full service IT audit firm specializing in SOC 2 Type 1 and Type 2 (including for SOC 2 for Cyber, CSA STAR, and Supply Chain) and HIPAA/HiTech. With a deep bench in cloud native technologies and modern security architectures, the Prescient audit team is a valuable partner in a compliance certification journey for any SaaS companies globally. Steve Seideman is a Principal Security Consultant at Prescient Assurance with over 25 years of InfoSec experience in both Big 4 and industry.