Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CPA] AUD: Internal Control Assessment: Applying the COSO Framework and Evaluating IT Systems
Transcript
- Hey, welcome to VoraPrep Audio. Let’s talk about internal controls. I know, I know… a lot of people think this topic is dry. Just a bunch of compliance checklists. But it’s the absolute heart of the audit. And if you need a reason why, think about that Wells Fargo scandal from a few years back. Employees created millions of fake accounts. That wasn’t some brilliant hack from the outside. It was a total breakdown on the inside. The pressure for sales was so intense, the ‘tone at the top’ was so broken, that it basically invited fraud. That’s a catastrophic failure of the Control Environment. And it shows you that the financial statements are only as good as the system that creates them. Understanding that system is your whole job as an auditor when you start an engagement. So what is "internal control," really? The official definition is that it’s a process, run by the company's people—from the board all the way down—designed to give *reasonable assurance* that the company is hitting its goals. And those goals fall into three buckets: reliable financial reporting, which is our main concern as auditors; efficient operations; and following the law. Management builds the system. We, the auditors, have to understand it to plan our audit. The model everyone uses for this is the COSO framework. It breaks internal control down into five connected pieces. For the system to work, all five have to be present and functioning. Think of it like building a house. You can't just have strong walls and no foundation. You need all the parts working together. The foundation of that house is the first component: the Control Environment. This is the "tone at the top" we were just talking about. It's the culture. Does the company value integrity? Does the board of directors actually provide oversight, or are they just rubber-stamping whatever the CEO wants? Is there a clear organizational structure? Do people know who they report to? And, importantly, are people held accountable when things go wrong? If this foundation is cracked—if the culture is rotten—nothing else you build on top of it is going to be reliable. Okay, so you've got your foundation. Next, you need the blueprints. And those blueprints have to account for potential problems. That’s the second component: Risk Assessment. This is *management’s* process for identifying and analyzing the risks that could stop them from achieving their goals. Not our risk assessment as auditors, but theirs. We just evaluate how good their process is. Are they looking for fraud risks specifically? Are they thinking about big changes in the business, like a new competitor or a new technology, and what risks that creates? If they aren't even looking for risks, how can they possibly build controls to stop them? Once you know the risks, you can build the walls, put locks on the doors, and install a security system. Those are the Control Activities. These are the actual policies and procedures—the guts of the system that make sure management’s directives are carried out. Things like requiring a supervisor's approval for a big purchase. Or segregating duties so the person who collects the cash can't also be the one who records it in the books. These are the specific actions taken to mitigate the risks you just identified. Now, a house needs wiring and plumbing to be useful. That's the fourth component: Information and Communication. You need good information flowing through the company to make all this work. Relevant, quality information. And it has to be communicated. Up to the board, down to the staff, across departments. If the sales team is using one system to track deals and the accounting team is using another, and they don't talk to each other… that’s a communication breakdown. That's a risk. It’s also about communicating externally—to auditors, to regulators—when things go wrong. Finally, even the best-built house needs inspections. That's the fifth component: Monitoring Activities. This is the process of checking to see if the other four components are actually working over time. Is the system still effective? This can be ongoing, like a manager who continuously reviews their team’s work, or it can be separate evaluations, like an internal audit department that comes in and does a formal review. The key is that when they find problems—deficiencies—they get reported to the right people so they can be fixed. So, to remember those five, a lot of people use the mnemonic CRIME. C-R-I-M-E. Control Environment, Risk Assessment, Information and Communication, Monitoring, and Existing Control Activities. It’s a bit dramatic, but it works. Now let’s get a little more specific, especially around technology. IT is woven into everything these days. So as an auditor, you have to look at two main types of IT controls. IT General Controls, or ITGCs, and Application Controls. Here’s the best way to think about it. Imagine a bank vault. The IT General Controls are the bank itself. The thick concrete walls, the security guards at the door, the rules about who can have the master key to the vault. They are pervasive. They protect the entire environment. Application controls, on the other hand, are the little individual keys to the safe deposit boxes *inside* the vault. They are specific to one task, like making sure only you can open your box. So, if the main vault door is left wide open and the security guards are all asleep—meaning your ITGCs are weak—does it really matter how strong the lock is on your little box inside? No. Of course not. An intruder can just walk in and steal the whole box. That’s why auditors focus on ITGCs first. If general controls like access controls—who has passwords, who can change the system's code—are a mess, then you can't trust any of the specific application controls. You just can’t. Let's walk through a quick example. Say you're auditing a company called FinTech Solutions. First, you look at the Control Environment. You find out the CEO’s bonus is almost entirely based on hitting short-term revenue goals. Huge red flag. That’s pressure from the top that could make people fudge the numbers. The foundation is shaky. Next, Risk Assessment. You ask how they handle risks. The CFO says, "Oh, we have a committee for that." But you find out they haven't met in over a year. They aren't actively looking for risks. The blueprint is out of date. Then you dig into Control Activities, specifically around revenue and IT. You find an Application Control that looks pretty good: the billing system automatically blocks a sale if a customer is over their credit limit. That's a nice, specific control. But then you look at the IT General Controls. You ask the head developer how they update the billing system. And he says, "Oh, I just push updates when they're ready." No testing. No approval. Nothing. That is a massive ITGC failure. Because of that, you can't rely on that neat credit-limit control you found. Why? Because the developer could change the code for that control anytime he wants, without anyone knowing. The vault door is wide open. You keep going. Information and Communication. The sales team tracks deals in one system, accounting uses another, and they don't sync up. That's a problem. And for Monitoring, there's no internal audit department. They basically wait for you, the external auditor, to find problems. So what's your conclusion? The tone at the top is bad, risk assessment is weak, a critical ITGC is broken, and there's no monitoring. You have to assess control risk as high. You can’t rely on their controls, which means you have to do a ton of extra substantive testing on revenue to get comfortable. Now, when you find these problems, you have to classify how serious they are. An exam might test you on the difference between a Control Deficiency, a Significant Deficiency, and a Material Weakness. It all comes down to two things: the potential *size* of the mistake it could cause, and the *likelihood* of it happening. A Control Deficiency is the lowest level. It's a flaw, but it's not likely to cause a material misstatement. You just tell management. A Significant Deficiency is more serious. It’s not material, but it's important enough that the people in charge of governance—like the audit committee—need to know about it. So you have to tell them, in writing. And then there's the big one: a Material Weakness. This is a bad one. It means there's a *reasonable possibility* that a *material misstatement* of the financials *will not* be prevented or detected. That has to be reported in writing to both management and those charged with governance. It’s a major finding. So the big takeaway for exam day is this simple inverse relationship: The stronger the controls, the less substantive testing you have to do. The weaker the controls, the more you have to test the actual account balances and transactions yourself. Always connect your control assessment back to your audit plan. If you want to practice connecting these concepts with exam-style questions and get explanations for why you got something right or wrong, check out VoraPrep. It’s a full exam-prep app with lessons, practice questions, and even an AI tutor to help you out. You can get started for free at Vora Prep dot com. To wrap up, remember the COSO framework is your blueprint—use CRIME. The Control Environment is the foundation. And when it comes to IT, weak general controls poison everything else. Your whole goal is to figure out if you can rely on the client’s system. If you can't, you have to ramp up your own work to make up for it. Okay, that's it for this one. Keep up the great work. I’ll talk to you next time.