cyBARR Chats Episode 16: Common SOC Exceptions

Transcript:

[00:00:00] Claire McKenna: Hello everyone. And welcome to today’s episode of cyBARR Chats. I’m Claire McKenna, senior writer and researcher with BARR. And today I’m joined by Katie Bialy, senior consultant with BARR cyber risk advisory practice to discuss common stock report exceptions. Stock report exceptions can happen more frequently than many realize.
So let’s learn a little bit more about what they mean and how they can impact the overall report. So Katie let’s get started. What is an exception in a stock report?
[00:00:31] Katie Bialy: Yeah. So an exception in the stock report is just an instance in which there is a deficiency in the design or the operating effectiveness of a control, or there is a system description misstatement. So there are three different types of exceptions that can happen in a stock report. And I’ll just walk through those three now in a little more detail. So the first is just system description misstatements. So a misstatement is an error in how an organization describes its systems. So just as an example, if you claim.
BARRs clients claim that all employees undergo security awareness training. And you say that in your system description, but your organization actually doesn’t require security awareness training. Then that would be a misstatement within the system description. I’ve actually never seen this happen with any clients I have worked with.
So I just wanted to note that it’s not really common. The next type of exception is deficiency in the design of a control. So this is when a control is ineffective because it wasn’t properly designed. So just as an example, if you have a control that a vendor risk assessment is performed by looking at your vendor’s attestation. But in reality, the process is to perform the assessment by only looking at vendor websites, then this would be an exception of design of a control. This is not as common because BARR works with our clients during the readiness assessment process to really make sure that controls are properly designed.
The last type of exception, the third one, which is a deficiency in the operating effectiveness of a control. This one is probably the most common type of exception that I’ll see. And this is when a control doesn’t operate properly or as it. Is expected. So just as another example, if you have a control in place that terminated user access to any of your in scope systems is removed within, let’s say one business day If that use, if there’s a user that BARR selects that has access removed to an in-scope system, let’s say one week after their term date, then this would be called out as an exception and exception in the operating effectiveness of a control. Again, this is the most typical type of exception that I see. Great.
[00:03:27] Claire McKenna: Yeah. Thank you for providing those examples. That was really helpful to understand each different type of exception. So that kind of my next question is really how common is it for stock report to list exceptions?
[00:03:41] Katie Bialy: Yeah, that’s really a great question. So, as I said, the first two type of exceptions, that what I went over, system description, misstatements and deficiency in the design of the control. It isn’t really common to see those type of exceptions, but the third type that I discussed, the deficiency and the operating effectiveness of a control, this type of exception is more common.
So I will say that typically with companies who have a less mature cybersecurity program, so let’s say a startup or a company that’s growing very rapidly. I will tend to see more exceptions for those type of. Clients or companies, but that being said, even companies who have mature cybersecurity programs, so maybe alar, larger organization who has gone through the SOC audit process many times sometimes even with these larger organizations they, they might have an exception, especially if a report is covering a one year period of time.
So. Just as an example. I mean, security awareness training is something that’s always tested during a SOC audit. If you are a company of say 500 people in BARR tests, a sample, or in other words, we, we take, uh, we take a selection of a certain employee. Say that one sample did not have security awareness training completed.
Then we would have to call that as an exception within the report. So you can see, it can be very easy for just one employee to be overlooked at larger organizations. Especially if that company isn’t using some kind of compliance tool, like an automated tool to, to track things like security awareness training. Got it.
[00:05:40] Claire McKenna: Yeah. Thank you for that example too. That’s that’s really helpful. Um, my next question is, so Katie, you’re an auditor. How do exceptions impact an auditor’s opinion?
[00:05:52] Katie Bialy: Yeah, another really great question. And I think it’s one where there’s maybe a little bit more confusion. So I think it’s something good to clarify. So. Whether or not an exception impacts the opinion really depends on the number of exceptions the severity of the exceptions. And before I get into the, the impact on the opinion, I just wanna say that the opinion, the auditor’s opinion is listed in section one of the SOC report, SOC reports have four or five sections Section five.
If, if the, uh, client wants to put any additional information there or there’s exceptions. So section one is where the opinion goes. . And so this opinion can be listed in four different ways. Um, one opinion, which is the most common type of opinion that we write is an unqualified opinion. And this just means that the auditor or say BARR that we didn’t find any material issues during the, the audit.
This is the opinion that service organizations, or you could say BARR clients that they strive for, and you can still have an unqualified opinion and have exceptions. So I just wanna note that as well. Now, the another type of opinion that we And that we can say is a qualified opinion. So this can happen as well.
I, I, again, not, it is common, but I have seen this qualified opinions indicate that the auditor or BARR found material issues with the report, but that the scope of the issues was limited. So I’ll just give an example here. For example maybe there’s just issues around testing of changes and this results in change, man management criteria, not being able to be met.
So if there are exceptions that result in criteria for SOC two or objective SOC one, if those aren’t able to be met, then this could result in a qualified report. The next type of opinion that is possible is an adverse opinion. And this is when the auditor BARR believes that there are material and pervasive issues.
So report readers should not rely on the vendor system. If the auditor BARR is issuing an adverse opinion. So this, for example, Could be if there’s issues around not just change management, but let’s also say logical ask access and risk management. So many different criteria, not very common. Um, but again, it is possible.
And the last opinion that we can issue is a disclaimer. And this is just that the auditor is unable to express an opinion due to insignificant or sorry, insufficient evidence, and the possible effects could be both. Um, material and pervasive. So, yep. Those are the different opinions and how exceptions can impact those opinions.
[00:09:35] Claire McKenna: Got it. Thank you for that kind of building off that a little bit. What do you do when you find an exception?
[00:09:45] Katie Bialy: Yeah. So another great question. If I find something some evidence during my testing, that looks as if a control is not designed appropriately or operating effectively. I would first just inquire of the client about the issue.
So it is often that a client has an explanation for the issue that I see or that I bring up. So, as an example, I worked with a client who was using an automation tool to track their vulnerabilities and this vulnerability This automation tool was showing that some vulnerabilities were not resolved within the time period that they should have.
So I brought up this issue to the client and they let me know that those vulnerabilities were just not tagged with the correct severity level. So it was just showing incorrectly. Um, that, that the resolution times were not being met. So in this case, I made a process improvement to the client about tagging severity levels on vulnerabilities, but it ended up not being an exception because of the client’s explanation.
Now in some other cases, I might inquire of my client about an issue and it’s actually confirmed that something was not designed or operating effectively throughout the period. Um, if it’s a, a type two report, so that’s covering a period of time A common example of this that I see probably most often is password configurations.
So a client has a password policy that mandates certain requirements, but those requirements are not enforced by configurations within a certain system that’s in scope. So in cases where something does look like an exception to me, and I’ve been confirmed. This with the client. Um, I’ve looked at the documentation.
Um, then I would go back to the internal team at BARR. So a manager or other people I work with just to confirm that my findings are accurate and. Then I can determine the impact on the criteria if it’s stock two or the objectives, if it’s stock one that this control helps to meet, because there potentially can be an effect on the opinion as I talked about earlier.
So I just wanna make sure that in exception is not going to result in an unqualified opinion, or if there’s multiple exceptions that it’s not gonna result in an adverse opinion. Um, and then from there we can determine If the exception was result in a qualification of any criteria as I just previously mentioned.
Um, and then as soon as possible, I would bring these findings up to the client and just really let them know the impact on the report. So will this have any impact on the auditor’s BARR’s opinion? Um, these are really important things that I think the client should know about.
[00:13:14] Claire McKenna: Great. Thank you for that answer.
That was really insightful. I wanna go back to something you mentioned earlier, you were discussing the different sections of a stock report. So which section of the report lists exceptions?
[00:13:25] Katie Bialy: Yeah. Great, great question. So, as I said earlier, There’s either four sections or five sections within a report. So in section four of the report the controls that are being tested are listed out there.
And any exceptions that we note from the controls that we tested will be included there. Now in section five of the report, if there are exceptions, we will also list them all. Um, together in one list and then the client has the ability to respond to each of the exceptions.
[00:14:08] Claire McKenna: Great to know about that. Um, that kind of leads to my next question.
So what should an organization do when they do have an exception in their stock report?
[00:14:18] Katie Bialy: Yeah. So an except or an organization should use exceptions as opportunities for improvement and working with a cybersecurity partner, like BARR can help the organization to understand. And. Address the exception BARR highly recommends that our clients, uh, resolve exceptions within the period, so that they’re able to talk about the remediation in the management response to the exception, which as I spoke about earlier, is it within the section five of the report?
[00:14:56] Claire McKenna: Great. Okay. Awesome to know. I just have one more question for you, Katie. Everything has been so insightful. Um, so you’re the expert. Is there anything else that you think organizations should know about stock report exceptions? Yeah.
[00:15:11] Katie Bialy: So I believe that utilizing automation, tools and monitoring and alarming mechanisms can really help to make sure that organizations are staying so compliant throughout, uh, the audit period, if it’s a type two report and reduce exceptions.
So for example, if you have a tool that alerts you, when you need to do. Let’s say annually, annual policy review and that approval you are so much more likely to stay compliant than if you just try to remember yourself. So having these tools and these automated alerting systems can really help you to make sure you stay compliant.
But although this is true, you can use these automation tools, there is still a human element to making sure that organizations stay compliant. So most compliance automation tools do not fully integrate with all of the client’s in scope systems in their stock report. So if that’s the case, Then like a human will still have to manually check to make sure let’s say in scope system, password configurations are in line with password policy.
Again, that’s just one example, but all of this. Just to say that there are definitely ways to help monitor compliance and reduce exceptions in stock reports, but it’s really not uncommon for exceptions to happen.
[00:16:52] Claire McKenna: That’s really great advice about utilizing automation tools. That was my last question. So Katie, thank you so much for all of your valuable insight on what organizations need to know about common stock report exceptions.
This information will definitely be very helpful for our clients. Um, and we just wanna also thank all of our viewers for tuning in and we look forward to seeing everyone next time on cyBARR Chats.
[00:17:17] Katie Bialy: Thanks Claire.