Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CISA] CISA2: IT Governance: Organizational Structure, Roles, and Segregation of Duties
Transcript
- Marcus: Ava, let's start with something that feels foundational: organizational structure. Why does an IS auditor care so much about an IT department's org chart? It seems a bit removed from the technical details. Ava: It seems that way, but it's often the root cause of major failures. There was a case at a financial firm where a developer managed to create a backdoor in a payment app, deploy it himself, and quietly siphon money for months. Marcus: Wow. So how did he get away with that? Ava: It was a total breakdown in what we call Segregation of Duties. He could write the code, approve his own changes, and push them to the live environment. No one else was involved. For an auditor, that's not a technical glitch. It's a massive governance failure that creates huge risk. Marcus: So the structure itself creates the opportunity. And I assume IT departments can be structured in different ways. Ava: They can. Broadly, you'll see centralized, decentralized, or hybrid models. The model an organization chooses tells you a lot about their culture and strategy. Marcus: Is one of those models inherently better or more secure than the others? Ava: Not necessarily. They each come with their own benefits and risks. Think about a large, regulated bank versus a fast-moving tech startup. The bank will likely have a centralized IT structure for tight, consistent control. The risk there might be that they're too slow to adapt. Marcus: And the startup? Ava: They might be decentralized, with IT people embedded in different teams to move quickly. The risk there is the opposite: a lack of consistent standards and controls. As an auditor, your job isn't to judge the model. It's to tailor your audit to the risks inherent in that model. Marcus: Okay, that makes sense. But the developer story you started with feels like a deeper issue. It wasn't just about centralized versus decentralized. It was about one person having too much power. What's the specific control that failed? Ava: You've hit on the core of today's lesson: Segregation of Duties, or S.o.D. It is one of the most fundamental preventive controls. Marcus: Preventive control. So its entire purpose is to stop something bad from happening in the first place, not just to clean up the mess afterward. Ava: Exactly. The goal is to ensure no single individual can both perpetrate and conceal an error or fraud. It's about building a process that requires more than one person to complete a high-risk action. Marcus: The classic analogy for this is the bank vault, right? The two-key system. Ava: It's the perfect way to picture it. One person has one key. A second person has a different key. You need both, at the same time, to open the vault. Neither can get in alone. Marcus: And how does that translate to the IT world? What are the 'two keys'? Ava: In the case of our rogue developer, writing the code is one key. Deploying that code to the live production environment is the second key. To protect the 'vault'—the production system where real transactions happen—those two keys must be held by different people. Marcus: So when we see a scenario about this on the CISA exam, how should we approach it? Those questions can be dense. Ava: There's a reliable four-step process to cut through the noise. The very first step is just to identify the core functions and the potential conflict. Marcus: So, you read the scenario. And you find where one person is wearing two different, conflicting hats. For example, being the person who creates a new user account, and also the person who authorizes what access that account gets. Ava: Precisely. Step one: spot the conflict. Once you've seen it, the second step is to pinpoint the specific control weakness. Marcus: Give it a formal name. So it's not just "Bob has too much power." It's "This is a failure of Segregation of Duties." Or maybe "This is an improper reporting line." Ava: Right. Naming the weakness clarifies your thinking for the next step, which is to evaluate the resulting risk. Marcus: What’s the worst that could happen here? Are we talking about data theft? Financial fraud? You’re really thinking about the business impact. Ava: Exactly. The severity of that risk tells you how urgent the issue is. And that leads directly to the final step: determine the BEST auditor action or control. Marcus: And I think this is where people get tripped up. The source material is very clear that the best answer is almost always a preventive control. Ava: Always. You want to recommend fixing the root cause, not just treating the symptom. You fix the broken process. You don't just install a camera to watch the broken process. Marcus: This is a great framework. Let's apply it to that worked example from the source material. The one about the senior developer, Bob. Ava: Perfect. So the scenario is this: Bob is the sole expert on a new accounts payable system. To get fixes done quickly, management has given him the ability to write code, test it himself, and deploy it directly to production. Marcus: Okay, let's use the framework. Step 1: Identify the conflict. That seems pretty clear. Ava: It is. Bob is performing development, testing, and operations. That’s three conflicting duties all wrapped up in one person. It's a critical S.o.D. violation. Marcus: Step 2: Pinpoint the weakness. We just named it—a failure of S.o.D. So, on to Step 3: Evaluate the risk. What's the worst-case scenario with Bob? Ava: It's about as high as it gets. He could write code to redirect payments to his own account. He could test it to make sure it works. Then he could deploy it without anyone knowing, and alter the system logs to hide his actions. He has total control. Marcus: That's a nightmare scenario. Which brings us to Step 4: the auditor's recommendation. What is the single most important thing the auditor should recommend? Ava: The first and best action is preventive and immediate: revoke Bob's access to the production environment. You have to separate the keys. Marcus: And then, you'd recommend they implement a proper change management process. A process where Bob writes the code, a separate QA team tests it, a manager formally approves it, and a different IT operations team is the only one that can deploy it. Ava: That's the correct, controlled process. You re-establish the two-key rule for the vault. Marcus: But what about management's original problem? They said they needed to do urgent fixes quickly. This multi-step process sounds slow. Ava: That's a valid business concern, and the auditor has to address it. You don't just say "no, you can't be fast." You recommend a formal emergency change process. It can be faster, but it must still involve oversight. For example, requiring a documented verbal approval from the CIO before a change is made. The core principle remains: you never let it collapse back to one person holding all the keys. Marcus: This is where that tempting-but-wrong answer comes in, isn't it? The one about just monitoring Bob's activity. Ava: Yes, this is a classic exam trap. An answer choice might be, "Recommend implementing a robust logging and monitoring solution for Bob's activities." It sounds reasonable. Marcus: But it's not the best answer. Why is it wrong? Ava: Because monitoring is a detective control. It only alerts you after the damage is done. S.o.D. is a preventive control. The CISA exam will always prioritize preventing the problem over detecting it after the fact. Marcus: Always choose preventing the fire over installing a better smoke detector. Got it. But what about really small organizations? A startup with just a couple of IT people can't always have perfect segregation of duties. Ava: That's a very practical question. When a preventive control like S.o.D. isn't feasible, an auditor looks for strong compensating controls. Marcus: Compensating controls. So these are things you do because you can't implement the primary, preferred control? Ava: Exactly. They don't prevent the action, but they are designed to detect it quickly. One common example is a formal, documented supervisory review. A manager with the right expertise closely reviews the detailed activity logs of the person with conflicting duties. Marcus: So someone is actively checking their work. What else? Ava: You can have robust audit trails, but the crucial part is that those logs must be reviewed by an independent party. And the logs themselves must be protected so the person being monitored can't change them. Marcus: The source also mentions forced job rotation. How does that work as a control? Ava: It's surprisingly effective. If someone is engaged in a fraudulent scheme, it often requires ongoing maintenance. Forcing them to rotate into a different role, even for a short time, can disrupt their ability to continue the fraud. Plus, the person taking over their duties is very likely to notice something isn't right. Marcus: So these compensating controls are useful, but they're still considered weaker than true S.o.D. Ava: Correct. As an auditor, you have to verify they are being performed consistently and effectively. You also have to confirm they reduce the risk to an acceptable level. Marcus: This is a lot to remember. Is there a simple mantra to keep the most critical IT separations straight? Ava: There is. Just remember this: "Devs don't Deploy, Admins don't Audit." Marcus: Okay, let's break that down. "Devs don't Deploy." Ava: Developers who write the application code should never be the ones with the permissions to move that code into the live production environment. That's the Bob scenario we just discussed. Marcus: And the second part: "Admins don't Audit." Ava: System administrators hold the keys to the kingdom. They manage the servers, the databases, the network. They should never, ever be in charge of the audit logs that track their own powerful activities. That's a massive conflict of interest. Marcus: That makes perfect sense. Speaking of conflicts of interest, the source has a very specific exam tip about the CISO's reporting structure. Ava: Yes, and this is a big indicator of an organization's security culture. On the exam, you need to know that a CISO, the Chief Information Security Officer, should be independent. The best structure is for them not to report to the CIO. Marcus: Why is that a conflict? They're both senior IT leaders. Ava: Because their missions can be at odds. The CIO is responsible for IT operations and delivery. The CISO is focused on managing risk. And managing risk often means adding controls that can make things slower or more expensive. Marcus: So if the CISO reports to the CIO, security priorities might get pushed aside to meet a project deadline or budget. Ava: Precisely. The CISO needs to be able to raise critical security issues without being overruled by operational pressures. To ensure that, it's much better for them to report directly to the CEO, the board of directors, or a Chief Risk Officer. That structure guarantees their independence. Marcus: This has been incredibly clear, Ava. We've covered the different IT organizational models. We talked about the absolute necessity of S.o.D. We went through that four-step process for analyzing exam questions. And we covered what to do when S.o.D. isn't perfectly achievable. Ava: And remember, understanding these governance concepts is foundational. They connect to so many other parts of the IS audit curriculum. Using that four-step process on practice questions is the best way to make it second nature. Marcus: That's excellent advice to end on. Thanks for the clear explanation, Ava. Ava: Any time. Keep up the great work with your studies, everyone. Marcus: VoraPrep is a full exam-prep app — lessons, practice questions, and an AI tutor in one place. Get started at Vora Prep dot com.