In this video, we walk through 5 ISC practice questions on COSO frameworks and cloud computing governance. These questions are from ISC content area 1 on the AICPA CPA exam blueprints: Information Systems and Data Management.
The best way to use this video is to pause each time we get to a new question in the video, and then make your own attempt at the question before watching us go through it.
COSO Frameworks and Cloud Computing Governance
The Two Frameworks
Two COSO frameworks are relevant to cloud governance. Neither is law, and neither prescribes specific technology.
- The Internal Control – Integrated Framework covers internal control over operations, reporting, and compliance. It organizes control into five components: control environment, risk assessment, control activities, information and communication, and monitoring activities.
- The Enterprise Risk Management framework addresses risk in relation to an organization’s strategy and objectives. Its five components are governance and culture, strategy and objective-setting, performance, review and revision, and information, communication, and reporting.
Both are voluntary structures that organizations adopt to organize how they think about control and risk. Regulators and auditors treat them as the reference point, which is why they became the default.
Assigning Authority and Accountability
Cloud governance depends on someone having been assigned authority and accountability for adopting cloud services. This is a control environment question, and it comes before everything else.
Consider a company where no person or committee approves cloud services. Three departments sign up for applications on department credit cards, and two of those applications end up storing customer data. Management finds out during an expense review.
The problem here is structural rather than procedural. A company in that position cannot assess the risk of these arrangements, design controls around them, or monitor them, because it does not know they exist.
The Frameworks Look at Cloud Arrangements Differently
ERM connects the arrangement to the organization’s objectives and risk appetite. A board deciding whether it is comfortable with client data sitting on machines the firm does not own, in a building it cannot enter, shared with other companies, is doing ERM work. That decision belongs to strategy and objective-setting.
ICIF addresses the specific controls used to manage the risks the arrangement creates. Who can access the system, who reviews that list, what the provider’s report says about the provider’s controls, and whether anyone confirms a year later that all of it still works.
Both frameworks apply throughout the arrangement. ERM does not close when the contract is signed, and ICIF does not wait for it, since controls have to be designed before a system goes live. The difference is what each framework is looking at, not when it applies.
Moving a System to a Provider
When a company moves its accounting system to a cloud provider, its financial reporting still has to be reliable, its data still has to be protected, and its access still has to be restricted. Those objectives are unchanged.
What changes is the method. The company no longer operates the environment and cannot inspect the controls running inside it. It obtains comfort over the provider’s controls indirectly, and it continues to perform the controls that remain on its own side.
The most consequential misconception in this area is that outsourcing the processing also outsources the responsibility. It does not. Management retains ownership of internal control over its processes even when a third party runs the systems those processes depend on.
What a SOC Report Covers
A SOC report is a report on the provider, written for the provider’s customers. It describes the provider’s controls over things like its data centers, system availability, and separation of one customer’s data from another’s. A Type 2 report goes further than a Type 1 and tests whether those controls operated over a period, which is what supports a conclusion about effectiveness rather than design.
The report also lists controls the provider expects each customer to perform. Those are there because the provider’s controls do not eliminate the risks created when the customer fails to perform its own.
So the report answers one of two questions. Reviewing it is important evidence and it is not sufficient by itself, and nothing in it shifts accountability for internal control to the provider.
