Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CISA] CISA4: Problem Management: From Firefighting to Permanent Fixes
Transcript
- Marcus: Welcome back to VoraPrep Audio's Office Hours. Today we're tackling a core CISA topic: Problem Management. Ava: And specifically, how we move from just putting out fires to making sure they never start again. Marcus, the source material has this intense example. It's about an e-commerce site that fails every single Black Friday. The IT team are heroes—they always get it back online. But the business is losing millions in the process. Marcus: Exactly. And that's the perfect entry point. Those heroes are practicing incident management. Their job is to restore service as fast as possible. But the fact that it happens every year tells us that no one is doing problem management. Ava: So incident management is the emergency response, and problem management is the detective work that follows. Marcus: That’s a great way to put it. Incident management is about speed and restoration. Problem management is about investigation and prevention. It's the process that finds and eliminates the underlying cause so the incident never happens again. Ava: Can you give us one of your analogies for that? It feels like a distinction the exam would definitely test. Marcus: Absolutely. Think of a dangerous intersection where crashes keep happening. Incident management is the paramedic arriving at the scene. Their goal is to stabilize the victim and get them to the hospital—fast, immediate, life-saving. Ava: Okay, they're stopping the bleeding. Marcus: Right. But problem management is the team of traffic engineers who show up a week later. They don't look at just one crash; they look at the pattern of all the crashes. They ask why this keeps happening. Ava: And they're the ones who decide to install a traffic light or put up better signs. Marcus: Precisely. The paramedic treats the symptom—the injury. The engineer fixes the root cause—the dangerous intersection. As an IS auditor, your job is to verify that the organization has those traffic engineers. You need to confirm they don't just have a really fast ambulance service. Ava: That makes sense. So if it’s a formal process, what does that look like? Are there defined stages? Marcus: There are. Most frameworks, like ITIL, lay out a clear lifecycle. We can remember the five key stages with the mnemonic D-LIR-C. Ava: D-LIR-C. Okay, let's walk through it. What's the 'D'? Marcus: 'D' is for Detect. A problem is identified. This isn't always a big bang. It could be from a single major incident, but more often, it's from noticing a pattern of smaller, recurring incidents. Or even proactively, by analyzing system performance trends. Ava: So someone in IT connects the dots and says, "Hey, the payment gateway has blipped out three times this month. That's not a coincidence." What happens next? The 'L'? Marcus: 'L' is for Log. The problem is formally recorded in a problem record. This is a critical step for an auditor. You want to see a single, central record for the problem that links out to every single incident it has caused. Ava: Why is linking those incidents so important? Marcus: Because it provides the full picture of the business impact. Think about it. Ten small incidents that each caused 15 minutes of downtime might not seem like a priority on their own. But when you log them against one problem, you suddenly see the real impact. It's caused two and a half hours of total downtime. Now, it gets the attention it deserves. Ava: Got it. So we've Detected a pattern and Logged it. Now for the 'I-R' in D-LIR-C. Marcus: 'I' is for Investigate and 'R' is for Resolve. They're two separate stages, but they're tightly connected. Investigation is the heart of the process. This is where you conduct a Root Cause Analysis, or RCA, to find that underlying flaw. Ava: This is the real detective work. Marcus: It is. The goal is to find the true 'why'. Once you have that, you move to 'R', Resolve. This is where a permanent solution is developed and implemented. Importantly, this fix should go through the formal change management process, which means raising a Request for Change, or RFC. Ava: So you don't just rush a fix in. You follow procedure to make sure the cure isn't worse than the disease. Marcus: You've got it. That ensures the fix is tested, approved, and deployed in a controlled way. Ava: That leaves 'C'. What's the final step? Marcus: 'C' is for Close. After you've confirmed that the fix was successful and has actually solved the problem, you formally close the problem record. A key part of this step is updating the organizational knowledge base. Ava: So the next time a similar symptom appears, the service desk has a record of what was done and why. Marcus: Exactly. It helps them diagnose future issues faster and prevents the organization from solving the same problem twice. So, the full lifecycle: Detect, Log, Investigate, Resolve, and Close. D-LIR-C. Ava: You mentioned Root Cause Analysis during the Investigation stage. That sounds critical. Let's make that more concrete with the worked example from the lesson—the recurring server crash. Marcus: Perfect. The scenario is an auditor reviewing a problem record for an application server that keeps crashing at a financial firm. The auditor needs to verify that a proper RCA was done. Ava: And the technique used here is the '5 Whys'. Marcus: Correct. It's a simple but powerful way to drill down past the obvious symptoms. The auditor would expect to see a trail of logic like this. First, Why did the server crash? Ava: Okay, the simple answer is: it ran out of memory. Marcus: Right. That's Why number one. Now, Why number two: Why did it run out of memory? The analysis shows a specific application process consumed all of it. Ava: So it's not the server hardware, it's a software issue. We're getting warmer. Marcus: Now for Why number three: Why did that process consume all the memory? Because it has a memory leak that was introduced in a recent software patch. Ava: Ah, the smoking gun! A bug in the code. It seems like we've found the root cause. Marcus: It's tempting to stop there, but a good auditor knows we have to keep going. We need to find the process failure, not just the technical one. So, Why number four: Why was a patch with a memory leak released to production? Ava: And the answer is that the pre-release performance testing didn't catch it. It didn't simulate peak load conditions. Marcus: Exactly. Which leads us to the final and most important question, Why number five: Why was the performance testing inadequate? The answer is that the QA team's testing protocols were outdated and didn't reflect current user transaction volumes. Ava: So the real root cause wasn't the code, it was the broken testing process that allowed the bad code to get through. That's what the IS auditor's recommendation should focus on. Marcus: That is the crucial takeaway. The tempting-but-wrong answer on an exam question would be to recommend something like "enhance server monitoring to detect memory leaks faster." Ava: Right, because that's still reactive. That's just a faster ambulance. It doesn't prevent the crash from happening in the first place. Marcus: Precisely. The auditor's primary recommendation has to be to update the QA testing standards. That addresses the process root cause and improves the control environment to prevent similar issues in the future. Ava: In the investigation stage, what happens if you find the root cause but can't fix it right away? Maybe the fix is too expensive or will take months to develop. Marcus: That's a great question, and it brings up another key concept: the Known Error. A Known Error is a problem where the root cause has been identified and a workaround exists, but a permanent solution isn't available yet. Ava: And these are stored somewhere specific? Marcus: Yes, in a Known Error Database, or KEDB. Think of it as a central library of problems-in-progress. It serves a few key purposes. It helps the service desk quickly find and apply workarounds for incidents, which speeds up restoration time. Ava: So it helps the incident management 'paramedics' do their job better while waiting for the 'engineers'. Marcus: Perfect analogy. It also prevents different teams from wasting time re-investigating the same problem over and over. And it gives management a clear, prioritized list of issues that need permanent fixes. For an auditor, a well-maintained KEDB is a sign of a mature IT organization. Ava: This all sounds great, but it also sounds very reactive. We're waiting for incidents to happen before we investigate. Do mature organizations get ahead of this? Marcus: They do. That's called Proactive Problem Management. Instead of waiting for the phone to ring, they actively look for trouble. They perform trend analysis on past incidents to find weak spots. They review risk assessments to identify potential future failures. Ava: So they’re trying to find the dangerous intersections before the crashes happen. Marcus: That's the goal. An auditor provides a lot of value by assessing this capability. Seeing evidence of trend analysis reports and preventative actions that came from them is a huge indicator of a strong operational control environment. Ava: This is all incredibly helpful. How do we boil this down for exam day? When we're looking at a scenario, how do we apply this? Marcus: Use a four-step framework. First, identify the core issue. Look for keywords like "recurring," "repeated," or "frequent." Those are your clues that this is a problem management issue, not just an incident. Ava: Step one: spot the pattern. Got it. Marcus: Step two, distinguish the goal. Is the answer choice about restoring service quickly, like rebooting a server? Or is it about finding the underlying cause? The first is incident management, the second is problem management. The CISA exam loves to test that distinction. Ava: Step three is about the cause, right? Marcus: Right. Look for the process-level cause. The BEST answer will almost always point to a failure in a process, not just a technical glitch. The memory leak was a technical issue; the inadequate testing protocol was the process root cause an auditor cares about most. Ava: And the last step? Marcus: Evaluate the proposed action against that D-LIR-C lifecycle. For a newly identified recurring issue, the correct first step is to log it and begin an investigation. An answer that suggests jumping straight to a fix without analysis is usually wrong. Ava: That framework really clarifies the auditor's perspective. It's about finding the weakness in the process, not just the technology. Marcus: Exactly. And that's the key takeaway. When you see recurring failures, think problem management. The best answer is about finding the root cause, not just treating the symptom. Look for the permanent, process-level solution. Ava: Find the traffic engineers, not just the paramedics. Thanks, Marcus. This was a great session. Marcus: My pleasure. VoraPrep is a full exam-prep app — lessons, practice questions, and an AI tutor in one place. Get started at Vora Prep dot com.