I got 99 problems, but SOD issues ain't one
I recently spoke at the 2023 DevOps Enterprise Summit (DOES) on the path to a better audit experience through Auditing with Agility. The event was incredible! Here's one of the amazing pics the photographer captured during my time on the main stage:
A number of attendees caught up with me after my session and commented about how the portion of my talk on segregation of duties (SOD) controls really resonated with them. Reading through the Slack comments that had been posted during my session confirmed this.
Since SOD controls, DevOps, and audit has been a hot topic for the past few years (audience members have asked me about it since my first DOES in 2019), I figured you all would benefit from a blog post on it. Specifically, many of you who work in technology want to know how to “pass” an audit when you no longer rely on traditional segregation of duties controls to manage the risk of bad things making it into production. Yes, this is a bit of a simplification, but you get the general idea.
When that comes up, I wonder what prompts such a question or request. I imagine it's prompted by a situation that goes something like this: Your auditors show up with an agenda or a checklist, or at least an idea of what THEY think they should be looking for. In their mind, they need to see evidence that duties are segregated in the software development or change process. Back in the day, that’s how you managed the risk of things getting into production that could break things. But today, let’s say you’re using automated tests in the development pipeline to manage that risk.
When the auditors ask for evidence of a Segregation of Duties control in place, and you can’t provide it (because that’s no longer how you’re managing that risk), they hand you an audit report with a finding because you don’t have these specific controls in place. They’re expecting you to put some outdated controls in place that, frankly, you don’t need—you’ve already got it covered.
Had they just used what’s called Integrated Planning, we wouldn’t be in this mess.
What is Integrated Planning, you ask? Well thank you for that question. So glad you asked! Integrated planning is where you and your auditors work closely together to build the scope of the audit and the plan for audit execution (sometimes referred to as the audit program or the risk and control matrix). You’ll help your auditors understand your objectives—what you’re trying to accomplish, risks—what could get in the way of achieving those objectives, and controls—what you do to manage those risks and set yourself up for success to accomplish what you’re trying to accomplish.
Now the scenario plays out like this: You and your auditor discuss your business (or product, process, or whatever else it is you're accountable for and he/she is auditing) so he/she understands what you're trying to accomplish and what success looks like to you. As part of that discussion, it's clear that one of the things that can get in the way of your success is bad things making it into production. If that happens, your app might go down and your end users–the business's clients–won't be able to access their accounts. Which means bad news for you and your company.
With this understanding, your auditor might jump to conclusions and assume that SOD controls are how that risk is managed (after all, you did manage it that way the last time they were here to audit you). But instead of the auditor drawing that conclusion in a silo and sticking with it throughout the audit, you're there to help steer him/her in the right direction. Because you're working closely with your auditor as he/she identifies which controls to test and how to test them, you explain to your auditor that you found a better way to manage that risk... let's say through automated tests in the development pipeline for purposes of this illustrative example. You help your auditor understand how the new control takes the place of the old SOD control and how it increases accuracy by reducing human error, reduces the risk of collusion and fraudulent activity, and is way more efficient.
Then you'll explain to your auditors how you know the automated test is working correctly, which will help them determine how to test this new control and what evidence they'll need to review. While you're at it, you both build out the audit request list together, so you both understand what documentation is needed. It's clear to you what you need to provide to your auditors as evidence for this control, and it's clear to them what the evidence will look like when you request it.
Now, instead of spending time asking about and expecting to review evidence for a control that isn’t in place (in this case, traditional SOD intentionally not in place), we focus on the control you do have in place and provide assurance on the design and operating effectiveness of that control. Wouldn’t you much rather know whether those automated tests doing what you need them to do, rather than get a report telling you to add a duplicative, manual control that you don’t need?
So with your next audit, suggest Integrated Planning. You’ll thank me later.
For more on Integrated Planning, see the following resources:
To Author Archive
Clarissa Lucas
Clarissa Lucas