What's Inside

So, you’re getting ready for your first SOC 2 audit. You’ve got your controls in place and have selected an audit firm to partner with. Now, it’s time for your observation period—and you’re concerned about exceptions.

What exactly are they, how do they impact your report, and how can you avoid them?

What is an audit exception?

An audit exception on a SOC 2 report is any instance where a control was not designed appropriately or did not operate as intended.

For example, let’s say one of your controls is that all employees use a password manager like LastPass to store passwords securely. If your auditor finds that three out of 50 employees they reviewed as part of a sample are not using LastPass, that would be listed as an exception.

There are typically three types of exceptions you’ll see come up in audits:

System description misstatements

A misstatement is an error (or omission) in how your business describes services or systems. These can be intentional or unintentional (maybe you left something out on purpose; maybe you made a change to the system and never updated your documentation)—but either way, they’ll be marked as misstatements.

For example, if you claim that new employees undergo security training, but you don’t actually have any security training in place, that’s a misstatement.

Deficiency in the design of a control

A design deficiency exception is when necessary controls are missing or an existing control is not properly designed, rendering it ineffective. For example, if you have a control in place for performing access reviews for key applications, but the process for obtaining the user lists for the review does not include all users, then a design deficiency would exist since the access review is not designed appropriately to include all users.

Deficiency in the operating effectiveness of a control

This is when a control doesn’t operate as expected. For example, if you have a control in place for performing background checks on new hires and during the audit the auditor determines that 50% of new hires did not have a background check performed, an operating effectiveness exception would exist.

Do exceptions mean we failed our audit?

The short answer is not necessarily. As you may already know, there are four types of auditor opinions that can be rendered at the end of an audit. Unqualified means you passed with flying colors. Your systems meet all SOC 2 criteria. Qualified means you came close. Things are looking good, but one or more SOC 2 criteria were not met. Adverse means your compliance needs work. Things are in bad shape and you do not meet most of the SOC 2 criteria. And disclaimer of opinion means the auditor could not obtain appropriate evidence to provide a basis for an opinion.

The good news is that not all exceptions impact your auditor’s opinion. If one control fails, but compensating controls are in place to mitigate the risk and meet the criterion, the auditor will note the control as an exception and determine that the criterion was still met with the compensating controls and render an unqualified opinion.

Whether your exceptions impact the opinion depends on their number, scope, and severity. Similarly, current and prospective customers will view exceptions differently based on their impact, how you respond, and whether they’re recurring or one-time events.

How to avoid audit exceptions

Leverage automation and best practices to ensure you’re doing everything possible to avoid exceptions in the first place.

Automate as much as possible

Keeping up with security can be time-consuming and challenging, which is why automation is your best friend. Automate monitoring. Automate your HR processes. Automate your technical checks—and the alerts that tell you if they’ve encountered an error. Ensure that the compliance automation solution you select provides the highest level of automation available. This supports instant and continuous visibility into your controls, allowing you to quickly remediate any gaps that may be occurring.

Monitor, monitor, monitor

If you don’t have automatic monitoring in place and your compliance starts to fail, you may not notice right away (thus derailing your audit). This is why one of the most important things you can do is set up automatic evidence collection, monitoring, and alerts with a partner like Drata.

Put someone in charge

If SOC 2 is everyone’s responsibility, it could very well end up as no one’s responsibility. While it’s important to have every team on board, it’s equally important to have someone who is responsible for knowing what controls you have in place, checking in, and keeping track of things like alerts or policy changes that impact your SOC 2. Like any other program, this one needs to be owned and maintained (reviewed, updated, etc.) by a clearly specified program manager whose roles and responsibilities are spelled out in detail.

Train your teams

The more informed the organization is, the better they can comply with your security standards. If you can build this training into the platform you use to track compliance (as you can with Drata), all the better.

Start with a SOC 2 Type 1 audit once your controls are in place

Many customers will require a Type 2 audit that covers at least six months, which means waiting six months after you have all your controls set up.

But rather than waiting six months and then finding out that something wasn’t quite right, we suggest conducting a point-in-time SOC 2 Type 1 audit as soon as everything is in place. This will help familiarize your auditors with your controls and systems and give you the confidence that in six months (or nine months or a year), your SOC 2 Type 2 audit will go smoothly.

Not to mention that a Type 1 audit is a great way to show current and prospective customers that you are currently compliant and are working toward long-term compliance, even if you can’t provide a Type 2 just yet.