Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CPA] ISC: Cloud Computing for ISC: Auditing the Shared Responsibility Model
Transcript
- Marcus: Welcome to VoraPrep Audio Office Hours. I’m Marcus. Ava: And I’m Ava. Today we’re covering a challenging topic: auditing cloud computing. Marcus: And it’s not just a tech topic. The source material kicks off with a story about a marketing department buying its own cloud service without telling IT. That sounds like a classic governance and risk problem. Ava: Exactly. It’s called ‘shadow IT,’ and it’s a huge issue. When a business unit stores sensitive customer data on an unvetted cloud platform, it creates a massive blind spot for the company and its auditors. Understanding who is responsible for what in the cloud is fundamental to risk assessment under the COSO framework. Marcus: So let's start with the basics. What officially defines something as “cloud computing”? Ava: The National Institute of Standards and Technology, or NIST, gives us five essential characteristics. For an auditor, each one introduces a specific risk that needs a control. Marcus: Okay, let's go through them. What’s the first characteristic? Ava: On-demand self-service. This means a user, say a developer, can provision a new server or a database automatically. They don't need to file a ticket with IT and wait a week. Marcus: That sounds efficient, but I can already see the risk. What’s to stop developers from spinning up dozens of expensive servers and just forgetting about them? Ava: You’ve nailed it. That’s the audit consideration. It can lead to uncontrolled costs, what we call ‘cloud sprawl.’ The control we’d look for is a governance process. This means clear rules on who can create resources, and automated policies that enforce spending limits. Marcus: Okay, that makes sense. What’s the second NIST characteristic? Ava: Broad network access. You can access cloud services from anywhere, on any device, over the internet. Marcus: Again, a huge business benefit. But for an auditor, that sounds like the front door to the company is now everywhere. Ava: It is. It dramatically increases the attack surface. The critical control here is strong authentication. We’re looking for things like mandatory Multi-Factor Authentication, or MFA. This ensures that only authorized users are getting in, no matter where they are. Marcus: Got it. What's number three? Ava: Resource pooling. The cloud provider pools its computing resources to serve many different customers from the same physical hardware. It's also called multi-tenancy. Marcus: So my company's data could be sitting on the exact same physical server as my competitor's data. How do we make sure there's no bleed-over? Ava: That's the key audit question. We can't test the physical server. So we rely on the provider to have strong logical controls that segregate each customer's data. We get assurance over those controls by reviewing their independent audit reports, which we’ll get to in a bit. Marcus: Okay, two more characteristics left. What’s next? Ava: Rapid elasticity. This is the cloud’s ability to scale resources up or down automatically based on demand. Think of an e-commerce site instantly adding more server capacity on Black Friday, and then scaling back down on Saturday. Marcus: So the risk isn’t technical, it’s more about financial planning? If the system can scale up on its own, the bill could be a surprise. Ava: Precisely. The process for defining and approving those auto-scaling rules becomes a key control. Auditors need to ask how the company manages and monitors that elasticity to ensure it aligns with budgets and capacity plans. Marcus: And the last one? Ava: Measured service. Everything in the cloud is metered. You pay for what you use, like a utility. Marcus: But those bills can be incredibly complex. How does an auditor handle that? Ava: They may need to. Part of an IT audit could be testing the accuracy of the cloud spending itself. And just as importantly, how it's allocated. Are the costs for that marketing platform you mentioned being correctly charged to the marketing department's budget? Marcus: That’s a great overview of the 'what'. Now let's get to the 'who'. The source material has a quick check question: if a company uses a provider like AWS, who’s responsible for patching the Windows Server operating system? Ava: And the answer to that defines the entire audit approach. It all depends on the service model. There are three main ones: Infrastructure as a Service, or I-a-a-S. Platform as a Service, or P-a-a-S. And Software as a Service, or S-a-a-S. Marcus: This is where people get confused. Is there a simple way to remember the difference? Ava: Absolutely. The best analogy is 'Pizza as a Service.' Marcus: Okay, I’m listening. Ava: Think of I-a-a-S as buying the raw ingredients from the store—flour, tomatoes, cheese. You have the most control, but you also have the most work. You're responsible for everything from the virtual machine's operating system on up. So in that quick-check question, with I-a-a-S, the customer is responsible for patching Windows. Marcus: Okay, so I-a-a-S is making the pizza from scratch. What about P-a-a-S? Ava: P-a-a-S is like getting a take-and-bake pizza. The shop provides the platform—the dough, sauce, and toppings are all assembled. You're just responsible for your application, which is baking it in your oven, and your data. The pizza shop—the provider—handles the underlying ingredients. Marcus: And S-a-a-S? Ava: S-a-a-S is ordering a pizza for delivery. It arrives ready to eat. The provider manages everything—the application, the platform, the infrastructure. You have the least work, but also the least control. You just manage who gets a slice—so, user access—and the data you put into the system. Marcus: That’s a fantastic analogy. So this division of labor has a formal name, right? Ava: It does. It’s called the Shared Responsibility Model. It is the single most important concept for auditing the cloud. The provider is responsible for security of the cloud—the physical data centers, the hardware. But the customer is always responsible for security in the cloud. Marcus: And what does "security in the cloud" always include, no matter which pizza you order? Ava: Your data and your user access. The customer always retains responsibility for classifying their data, protecting it, and managing who is allowed to see it. That’s a critical point for the exam. Marcus: So if I'm auditing a company using the cloud, I can't just go visit the provider's data center. How do I get assurance that they’re handling their side of the responsibility model? Ava: You rely on their System and Organization Controls report, or SOC report. It’s an independent audit of the cloud provider's control environment, performed by another CPA firm. Marcus: The source material mentions a few different kinds. SOC 1, SOC 2... what’s the difference? Ava: A SOC 1 report focuses on controls relevant to the client's internal control over financial reporting. You’d need this if your client is using a cloud-based payroll or revenue system. A SOC 2 report is much broader. It reports on controls related to five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. It's the most common one you'll see. Marcus: And then there's Type 1 versus Type 2. That seems like a critical distinction. Ava: It is. A Type 1 report only gives an opinion on the design of the controls at a single point in time. It's very limited. A Type 2 report tests both the design and the operating effectiveness of the controls over a period, usually six to twelve months. For any critical system, you expect to see a SOC 2, Type 2 report. Marcus: So let's say I get a clean SOC 2, Type 2 report from my client's cloud provider. That means their security is solid and my audit work is done, right? Ava: That is the most common and dangerous mistake an auditor can make. It’s the ‘SOC. Report Seal of Approval’ fallacy. Marcus: Why is it a fallacy? Ava: Because the SOC report is only valid if your client, the customer, implements their own required controls. These are called Complementary User Entity Controls, or CUEC.s. The SOC report itself will explicitly list them. Marcus: So the provider's security depends on the customer doing their part. Can you give me an example of a CUEC and how I would actually audit it? Ava: A classic CUEC would be something like: "The user entity is responsible for reviewing user access rights on a quarterly basis." To audit that, you can't just rely on the provider's SOC report. You have to test your client's process. Marcus: So I’d ask management for evidence of those reviews. Ava: Exactly. You’d inspect the documentation for the last four quarters to see if they were actually performed and signed off. Then you’d select a sample of employees who left the company. You would trace them to the system to verify their access was revoked in a timely manner. If the client fails to do this, the whole control system falls apart, regardless of how good the provider’s controls are. Marcus: This really brings it all together. Let’s apply this to the worked example from the source material. Apex Manufacturing is moving its accounting system to a S-a-a-S provider, FinCloud. As the auditor, what’s my first step? Ava: Step one is always to identify the service model. It’s S-a-a-S. This immediately tells you that Apex is responsible for managing user access and configuring application-level controls. They are NOT responsible for things like patching the operating system FinCloud runs on. Marcus: Okay, so step two must be getting the evidence for FinCloud's side of things. Ava: Right. You’d request their SOC report. Since it’s an accounting system that impacts financial reporting, you need the SOC 1, Type 2 report. You’d check that it has a clean opinion. You also need to make sure the report’s time period covers the period you’re auditing for Apex. Marcus: Let's assume the SOC report is clean. Now my focus shifts entirely to Apex, right? Step three. Ava: Correct. You read the CUEC section of the FinCloud report. This lists the controls Apex is required to perform. Things like restricting user access based on least privilege, performing those quarterly access reviews, and promptly removing terminated employees. Marcus: And step four is to actually test those CUEC.s at Apex. Ava: Exactly. You design your audit procedures to test Apex’s performance. You’d sample users to check their permissions, you’d ask for the quarterly review evidence, and you’d trace a list of terminated employees to make sure their access was removed. Marcus: The example concludes that Apex failed to do the quarterly reviews, and several terminated employees still had active accounts. So even with a clean SOC report from the provider, what's my conclusion as the auditor? Ava: You have to conclude there is a significant control deficiency at Apex. The failure is unequivocally their responsibility. The S-a-a-S provider has no way of knowing when Apex fires an employee. That’s a classic CUEC, and Apex failed to execute it. Marcus: That four-step framework—identify the model, pinpoint responsibility, determine the evidence, and then evaluate the control—is incredibly clear. It seems like the key to deconstructing any cloud question on the exam. Ava: It is. And it all starts with getting that first step right. Nail the service model—I-a-a-S, P-a-a-S, or S-a-a-S—and you're halfway to the right answer. Let's hammer home the key takeaways. First, remember the five NIST characteristics that define cloud computing. Second, the service model determines who is responsible for what, but the customer is always responsible for their data and user access. Marcus: Third, SOC reports are the main evidence for the provider’s controls, and a Type 2 report is the gold standard because it covers operating effectiveness over time. Ava: And finally, and most importantly, an auditor’s primary job is to test the client's implementation of their Complementary User Entity Controls, the CUEC.s. That is where you will find the control failures. Marcus: Perfect summary. Ava, this was incredibly helpful. Thanks. Ava: You got it, Marcus. 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.