Home / CPA Course / ISC

IT infrastructure and cloud computing

ISC Chapter 1 · Area I · Blueprint I.A.1

Every control you will meet in ISC sits on top of some piece of technology: a server, a network, a cloud service. This chapter gives you the map. Priya, the IT audit specialist at Hart & Vale LLP, and Sam, a new associate, walk through Brightwater Outfitters, an outdoor gear retailer with 40 stores and a busy website, as it decides what to keep in its own server room and what to move to the cloud. By the end you can name each part of an IT architecture, tell IaaS from PaaS from SaaS, match a deployment model to a business, say who is responsible for what in the cloud, and explain how COSO's guidance helps a board govern it.

In this chapter

1. The pieces of an IT architecture
2. Networks that carry the data
3. Cloud computing: renting instead of owning
4. Service models: IaaS, PaaS and SaaS
5. Deployment models: public, private, community and hybrid
6. What the cloud provider does, and what the contract must say
7. Governing the cloud with COSO

This chapter has 7 lessons, 50 practice MCQs with explanations and 20 simulations, plus flashcards and a recall sheet.

What this chapter covers

• Operating systems, servers, networks and end-user devices
• IaaS, PaaS and SaaS
• public, private and hybrid clouds
• provider responsibilities
• COSO and cloud governance

Chapter 1 is free to read in full. Here are its lessons.

The pieces of an IT architecture

An IT architecture is the set of layers that together deliver a business system: hardware, operating systems, servers, storage, networks, applications, data and the end-user devices people use. Each layer depends on the ones below it.

The operating system (Windows, Linux, macOS, iOS, Android) manages the hardware, memory, files and user accounts, and lets applications run. Weak operating system settings can undo strong application controls, because an administrator at that layer can reach the data directly.

A server is a computer that provides a service to other computers. Servers are named by their job: web servers show pages, application servers run business logic, database servers store and retrieve data, file and email servers do what their names say, and directory servers hold user accounts and passwords.

Most servers today are virtual machines: software copies of a computer that share one physical host through a hypervisor. Virtualization saves money and speeds up setup, but it concentrates risk on the host.

End-user devices (desktops, laptops, tablets, phones, point-of-sale terminals, scanners, printers) are where data enters and leaves. They are also where many attacks start.

Example. A clerk keys a refund at a POS terminal. The terminal (end-user device) sends it over the store network to the application server, which writes it to the database. Every layer must be controlled for the refund record to be trusted.

Step up. A store clerk scans a jacket. The handheld scanner (end-user device) sends the code over store Wi-Fi (network) to the application server, which asks the database server for the price. The answer comes back the same way. Five layers worked for one beep.

Exam level. Brightwater runs 12 virtual servers on 2 physical hosts. A failure of one host takes down every virtual server on it, so the risk sits at the host (hypervisor) layer. Good design spreads the web, application and database servers across both hosts so one failure does not stop sales.

Watch out. Candidates think the application is the whole system. Questions often describe a problem at the operating system, database or network layer and ask which control would catch it. Look for the layer where the problem starts.

Networks that carry the data

A network moves data between devices. A local area network (LAN) covers one site; a wide area network (WAN) joins sites; the internet is the largest WAN of all. Wireless networks (Wi-Fi) do the same job without cables and need their own security settings.

Switches connect devices inside a network; routers pass traffic between networks and choose the route; firewalls allow or block traffic based on rules about addresses, ports and protocols. A load balancer shares traffic across several servers so no single one is overwhelmed.

DNS (the domain name system) turns names such as brightwater.example into numeric IP addresses. If DNS fails or is tampered with, customers cannot reach the site, or reach a fake one.

Networks are often divided into zones. Public-facing servers sit in a demilitarized zone (DMZ); sensitive systems sit deeper inside behind more filtering. Chapter 12 builds on this idea as segmentation and defense in depth.

Example. A firewall rule allows inbound traffic on port 443 (HTTPS) to the web servers and blocks everything else from the internet. Customers can shop; nobody outside can reach the database directly.

Step up. A LAN links the devices inside one store. The 40 stores, the warehouse and head office are joined into a WAN over leased lines and encrypted internet links. A router sends traffic between these networks; a switch connects devices within each one.

Exam level. Brightwater puts its web servers in a DMZ, a separate zone between two firewalls. If an attacker takes over a web server, the inner firewall still blocks direct access to the database segment. That is network design acting as a preventive control.

Watch out. Routers and switches are confused on the exam. A switch connects devices within one network; a router connects different networks. A firewall filters; it does not route by itself in exam questions.

Cloud computing: renting instead of owning

Cloud computing means using computing resources (servers, storage, networks, software) over the internet from a provider's shared pool, instead of owning them. The NIST definition (SP 800-145) names five essential characteristics.

On-demand self-service: the customer adds resources without calling anyone. Broad network access: resources are reachable from many devices over the network. Resource pooling: one provider serves many customers (multi-tenancy) from shared hardware.

Rapid elasticity: capacity grows and shrinks quickly, often automatically. Measured service: use is metered and billed, like electricity.

Benefits include lower upfront cost, scalability, speed, and access to the provider's security staff and data centers. Risks include dependence on the provider, less visibility into its controls, data stored in other countries, vendor lock-in, and surprise costs.

Example. A tax-season bookkeeping firm needs 50 laptops' worth of processing in March and 10 in July. A cloud service that scales up in March and down in July is using rapid elasticity and measured service.

Step up. On premises, Brightwater must own 58 servers all year to survive November. In the cloud it runs about 12 to 20 most months and scales to 58 for a few weeks, paying only for what it uses.

Exam level. Moving to the cloud turns capital expenditure (buying servers) into operating expenditure (monthly fees). It also moves some control work to the provider, but not the accountability: Brightwater still owns its data, its user access and its compliance with laws such as PCI DSS.

Watch out. Do not equate cloud with outsourcing responsibility. The provider runs the infrastructure, but the customer remains responsible for its data, access and compliance. Exam answers that say the risk has moved entirely to the provider are wrong.

Service models: IaaS, PaaS and SaaS

Infrastructure as a Service (IaaS) rents the basic building blocks: virtual servers, storage and networks. The customer installs and manages the operating system, middleware and applications. It gives the most control and the most work.

Platform as a Service (PaaS) adds the operating system, runtime and database engine. The customer builds and runs its own applications on the platform without managing servers. Developers like it because they can focus on code.

Software as a Service (SaaS) delivers a finished application over the internet, usually by subscription: email, payroll, CRM, many ERPs. The customer configures it and manages users and data; the provider does the rest.

Other offerings follow the same pattern: security as a service, database as a service, disaster recovery as a service. The test is always which layers the customer still manages.

As you move from IaaS to SaaS, the provider takes on more layers and the customer gives up control and visibility. The customer's reliance on the provider's controls, and on its SOC reports (chapter 17), grows accordingly.

Example. A company uses a hosted email service through a browser and never sees a server: SaaS. It must still set password rules, assign mailboxes and remove leavers' accounts.

Step up. Brightwater rents virtual servers and installs its own Linux and web software: IaaS. Its developers build a returns app on a provider platform that supplies the database and runtime: PaaS. Its staff use a hosted payroll system through a browser: SaaS.

Exam level. An auditor asks who patches the operating system under the returns app. Under PaaS, the provider does; under IaaS, Brightwater does. For every model, Brightwater still controls who has user access and must review it. That line never moves to the provider.

Watch out. The most tested slip is thinking SaaS removes all customer duties. Under every model the customer owns its data, decides who gets access, and configures the application. User access reviews are always the customer's job.

Deployment models: public, private, community and hybrid

A public cloud is owned by a provider and shared by many unrelated customers. It offers the lowest cost and the fastest scaling. Customers are separated logically, not physically.

A private cloud serves one organization. It may sit in the company's own data center or be hosted by a provider on dedicated hardware. It gives the most control and is common for highly sensitive data.

A community cloud is shared by organizations with common concerns, such as security requirements or regulation, and may be run by them or by a provider. A hybrid cloud links two or more of the other models so data and applications can move between them.

Using several providers at once is multi-cloud. It reduces reliance on one provider but adds integration work and more places where a setting can be wrong. The deployment choice should follow the sensitivity of the data and the business need, not fashion.

Example. A city government, a county and a school district share a cloud set up to meet the same public records rules: a community cloud.

Step up. Brightwater keeps its ERP database in a private cloud hosted by a provider, runs its website in the public cloud, and links them: a hybrid cloud.

Exam level. Five regional hospitals share one cloud built to meet HIPAA rules and split the cost: a community cloud. If one of them also uses a second provider's public cloud for email, that hospital is multi-cloud, which spreads dependence but multiplies the contracts and settings to control.

Watch out. Private does not mean on premises. A private cloud can be hosted by a provider, as long as the infrastructure is dedicated to one organization.

What the cloud provider does, and what the contract must say

A cloud service provider (CSP) owns and runs the infrastructure and services it sells. Its typical duties: physical security of data centers, power and cooling, hardware upkeep, the network and virtualization layers, availability of the service, and, for PaaS and SaaS, patching of the platform or application.

Under the shared responsibility model, the provider secures the cloud itself and the customer secures what it puts in the cloud. The split moves with the service model, but data classification, user access and compliance stay with the customer.

The service level agreement (SLA) sets measurable promises such as availability, response times and support hours, and the remedy if they are missed, often only service credits. The wider contract should cover security duties, audit rights or SOC reports, data location, encryption, breach notification, subcontractors, and exit terms: how data comes back and is deleted.

Customers monitor providers by reading their SOC 2 (or SOC 1) reports each year, checking the complementary user entity controls the customer must run, tracking SLA results, and reviewing incidents. Chapters 17 to 19 cover those reports in depth.

Example. A SaaS payroll provider's SOC 2 report lists a user control: customers must remove access for terminated employees. Brightwater must run that control itself or the provider's controls will not be enough.

Step up. 99.9% availability over a 30-day month (43,200 minutes) allows 43.2 minutes of downtime (43,200 x 0.1%). At 99.99% it is about 4.3 minutes.

Exam level. Availability measured at the provider's network edge, excluding announced maintenance, can be met even when Brightwater's customers cannot check out because of Brightwater's own misconfigured server. The SLA measures only what the provider controls. Brightwater must monitor end-to-end availability itself.

Watch out. An SLA credit is not insurance. Exam answers that say the SLA protects the customer from business losses are usually wrong; it caps the provider's exposure to a bill discount.

Governing the cloud with COSO

COSO's guidance Enterprise Risk Management for Cloud Computing applies the ERM framework to the cloud. Its message: a cloud decision is a business decision, governed by the board and management like any other risk, not left to IT alone.

It walks through the ERM components: the internal environment (governance, policies, who may sign up for cloud services), objective setting (why use the cloud, within what risk appetite), event identification, risk assessment, risk response, control activities, information and communication, and monitoring.

Cloud risks it highlights include unauthorized use of cloud services by business units (shadow IT), reduced transparency into the provider's controls, reliability and performance, data location and regulatory compliance, cyberattacks on a shared environment, and vendor lock-in with poor portability.

Practical governance actions follow: an approved cloud strategy, a policy that routes every cloud purchase through review, due diligence on providers, contracts that fix rights and duties, and ongoing monitoring through SLA reports and SOC reports. Chapter 12 shows COSO's separate guidance on cyber risk.

Example. A marketing team signs up for a cloud survey tool that collects customer emails. Under COSO's cloud guidance this is unauthorized cloud use: the internal environment should require approval so the data and the vendor are assessed first.

Step up. COSO's guidance treats moving payroll to the cloud as a business decision with its own risks. Brightwater's board sets the objective (lower cost, scalable payroll), the risk appetite (no payroll data outside the U.S.), and asks management to identify cloud-specific events.

Exam level. Management finds three risks: unauthorized cloud use by departments, the provider's subservice data center, and lock-in from a proprietary data format. Responses: a cloud purchasing policy approved by the CIO (reduce), a contract clause for standard-format data export (reduce), and accepting the remaining dependency inside appetite. Monitoring: annual SOC 2 review and quarterly SLA reports to the audit committee.

Watch out. COSO does not tell a company which provider to choose or which technical settings to use. It gives a governance and risk structure. Answers that describe COSO as a technical security standard are wrong; that is NIST or CIS.

Chapter 2: Enterprise and accounting information systems