2.2 Cloud Computing Service & Deployment Models

2.2 Cloud Computing Service & Deployment Models

Quick Answer: Cloud computing delivers computing infrastructure, development platforms, and business applications over the network on a metered basis. The National Institute of Standards and Technology (NIST SP 800-145) establishes five essential characteristics, three service models (IaaS, PaaS, SaaS), and four deployment models (Public, Private, Hybrid, Community). For CPA auditors, the critical concept is the Shared Responsibility Model: while physical datacenter security shifts to the cloud service provider (CSP), user organizations always retain legal and operational accountability for data classification, identity and access management (IAM), and compliance governance.

---

1. NIST SP 800-145 Definition & Five Essential Characteristics

The National Institute of Standards and Technology Special Publication 800-145 (NIST SP 800-145) provides the globally recognized benchmark definition of cloud computing:

"A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

To qualify as true cloud computing under NIST, an environment must exhibit all five essential characteristics:

1. On-Demand Self-Service: A consumer can unilaterally provision computing capabilities—such as server instances, block storage, and network interfaces—automatically without requiring human interaction with the service provider.
2. Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, workstations).
3. Resource Pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with physical and virtual resources dynamically assigned and reassigned according to consumer demand. The customer generally has no control or knowledge over the exact physical location of the provided resources (location independence), though they may specify location at a higher level of abstraction (e.g., country, state, or availability zone for data residency compliance).
4. Rapid Elasticity: Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, available provisioning resources often appear unlimited.
5. Measured Service: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer.

---

2. Cloud Service Models: IaaS, PaaS, and SaaS

Cloud computing architectures are categorized into three standardized service tiers, each offering different levels of customer control and administrative abstraction.

Infrastructure as a Service (IaaS)

IaaS provides raw, virtualized computing resources over the Internet. The consumer rents fundamental computing building blocks: virtual machine instances, raw block or object storage, and virtual network appliances.

• Examples: Amazon Web Services (AWS EC2, S3), Microsoft Azure Virtual Machines, Google Cloud Compute Engine.
• Customer Authority: The customer does not manage or control the underlying cloud physical infrastructure or hypervisor, but retains complete control over the guest operating system, storage allocations, installed applications, and virtual network firewalls (security groups).
• Audit Consideration: IaaS environments require the exact same ITGC rigor as on-premises physical servers. The customer must configure operating system patching, anti-malware, local user account controls, and database backups.

Platform as a Service (PaaS)

PaaS provides a managed hardware, operating system, and software framework designed for software development, database execution, and container orchestration.

• Examples: AWS Elastic Beanstalk, Google App Engine, Microsoft Azure App Services, Snowflake, AWS RDS (Relational Database Service).
• Customer Authority: The customer controls deployed applications and configuration settings for the application-hosting environment. The CSP manages the underlying physical infrastructure, network architecture, hypervisor, operating system installation, and automated OS security patching.
• Audit Consideration: Operating system patching and hardware maintenance are outsourced to the CSP. The auditor's focus shifts to application-level development controls, code vulnerability scanning, API security configurations, and database access permissions.

Software as a Service (SaaS)

SaaS provides complete, turnkey software applications accessible via a web browser, mobile client, or programmatic API.

• Examples: Salesforce, Workday, Microsoft 365, ServiceNow, NetSuite.
• Customer Authority: The customer has no control over the underlying infrastructure, operating system, network, or application code. The customer controls only application configuration parameters, user role provisioning, and the data ingested into the system.
• Audit Consideration: ITGC testing of operating systems and database architecture is inapplicable for the user entity. Instead, the auditor evaluates business process controls, user access management (e.g., timely revocation of terminated users), role-based access control (RBAC), multi-factor authentication (MFA), and data export/backup configurations.

---

3. The Cloud Shared Responsibility Model

The Shared Responsibility Model dictates which security, operational, and regulatory controls are managed by the cloud service provider versus the cloud consumer. Control boundaries shift dramatically depending on the chosen service model.

+-----------------------------------------------------------------------------------------+
| Control Layer                     | On-Premises   | IaaS          | PaaS          | SaaS|
+-----------------------------------------------------------------------------------------+
| Data Classification & Governance  | Customer      | Customer      | Customer      | Customer|
| Identity & Access Management (IAM)| Customer      | Customer      | Customer      | Customer|
| Endpoint & Client Device Security | Customer      | Customer      | Customer      | Customer|
| Application Code & Configuration  | Customer      | Customer      | Customer      | CSP     |
| Middleware & Database Engines     | Customer      | Customer      | CSP           | CSP     |
| Operating System & Patching       | Customer      | Customer      | CSP           | CSP     |
| Hypervisor & Virtualization       | Customer      | CSP           | CSP           | CSP     |
| Physical Servers & Storage        | Customer      | CSP           | CSP           | CSP     |
| Physical Datacenter Security      | Customer      | CSP           | CSP           | CSP     |
+-----------------------------------------------------------------------------------------+

The Cardinal Rule for CPA Auditors

Exam Watch: No matter which service model is utilized—even turnkey SaaS—the customer ALWAYS retains ultimate accountability for data governance, data classification, and user access authorization. A company cannot contract away legal liability or financial reporting responsibility by claiming that a cloud provider failed to secure their financial data.

---

4. Cloud Deployment Models

NIST SP 800-145 identifies four distinct cloud deployment architectures, each balancing cost efficiency, control, and security isolation differently.

Public Cloud

The cloud infrastructure is provisioned for open use by the general public. It exists on the premises of the cloud provider and is owned, managed, and operated by a commercial vendor (e.g., AWS, Azure, GCP).

• Advantages: Massive economies of scale, no capital infrastructure expenditure (CapEx converted to OpEx), near-infinite elasticity.
• Inherent Risks:
  • Multi-Tenancy Risks: Computing resources are shared across thousands of unrelated corporate tenants. Logical misconfigurations or hypervisor zero-day exploits could theoretically expose one tenant's data to another.
  • Jurisdictional / Sovereignty Risks: Cloud providers dynamically balance server loads across global regions. If financial records or customer PII are replicated to datacenters in foreign jurisdictions, the data may become subject to foreign laws, conflicting with domestic regulations (e.g., GDPR, HIPAA).

Private Cloud

The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.

• Advantages: Dedicated hardware ensures complete physical and logical isolation. Highly predictable performance with zero "noisy neighbor" risk. Fully customizable to strict regulatory standards.
• Disadvantages: Significant upfront capital investment, ongoing internal engineering overhead, and limited elasticity compared to public hyperscalers.

Hybrid Cloud

The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability.

• Key Use Cases:
  • Cloud Bursting: An enterprise runs its baseline accounting operations in a private cloud, but automatically "bursts" intensive non-sensitive computational workloads (e.g., end-of-quarter analytics simulations) to a public cloud during peak processing windows.
  • Sensitive Data Tiering: A healthcare entity maintains patient health records (PHI) on an on-premises private cloud while hosting public-facing patient portal interfaces on a public cloud.
• Audit Challenges: Requires robust, encrypted interconnects (e.g., IPsec VPN tunnels, AWS Direct Connect, Azure ExpressRoute) and unified identity management (e.g., federated Single Sign-On via SAML/OAuth) across disparate private and public boundaries.

Community Cloud

The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations).

• Example: AWS GovCloud or Microsoft Azure Government, restricted exclusively to U.S. federal, state, and local government agencies and defense contractors adhering to FedRAMP High and ITAR compliance standards.

---

5. Cloud Governance, Auditor Reliance & SOC Report Evaluation

When an organization migrates critical financial reporting systems or sensitive data to the cloud, the CPA auditor must evaluate how management governs third-party risk.

The Fallacy of Outsourced Accountability

A common audit finding in SOC 2 and financial statement audits is management's mistaken belief that migrating to the cloud relieves them of control responsibilities. Auditors evaluate whether management has established:

• Cloud Security Policies: Formal policies governing cloud service provisioning, cryptographic key management, and approved cloud storage configurations.
• Shadow IT Monitoring: Discovery mechanisms (such as Cloud Access Security Brokers - CASBs) to detect employees provisioning unauthorized SaaS tools or uploading corporate data to unapproved cloud repositories.
• Cloud Configuration Audits: Periodic automated assessments of cloud security postures (CSPM tools) to detect misconfigured cloud storage buckets (e.g., publicly accessible AWS S3 buckets), unencrypted databases, and over-permissive identity policies.

Evaluating Third-Party SOC Reports

Because auditors cannot independently enter a cloud hyperscaler's physical datacenter to inspect server racks or test hypervisors, they rely on System and Organization Controls (SOC) attestation reports issued by independent service auditors:

1. SOC 1 Type 2 Reports (SSAE 21 / AT-C 320): Evaluates controls at a service organization relevant to user entities' Internal Control over Financial Reporting (ICFR). If an organization runs its general ledger on a cloud ERP (e.g., NetSuite), the financial statement auditor must inspect the cloud provider's SOC 1 Type 2 report covering the audit period.
2. SOC 2 Type 2 Reports (AT-C 205 / Trust Services Criteria): Evaluates controls relevant to Security, Availability, Processing Integrity, Confidentiality, and Privacy. Critical for assessing data security, system uptime, and operational resilience.

Complementary User Entity Controls (CUECs)

A service auditor's unqualified (clean) opinion on a cloud provider's SOC report is predicated upon the customer implementing specific internal controls, termed Complementary User Entity Controls (CUECs).

Key Concept: If a cloud provider's SOC 2 report states that access to customer data is protected, but lists a CUEC requiring the customer to enforce multi-factor authentication (MFA) and promptly terminate departed employees' credentials, the auditor cannot rely on the cloud provider's security controls unless the auditor verifies that the customer has properly designed and operated those CUECs.

Complementary Subservice Organization Controls (CSOCs)

Cloud service providers frequently rely on downstream subservice organizations (e.g., a SaaS provider hosting its platform on AWS IaaS). The service auditor can present subservice organizations using two reporting methods:

• Carve-Out Method: Excludes the subservice organization's control objectives and tests from the report, requiring user auditors to obtain and evaluate the subservice organization's separate SOC report.
• Inclusive Method: Includes the subservice organization's controls within the scope of the examination and testing.

Bridge Letters (Gap Letters)

SOC reports cover a specific historical testing window (e.g., October 1 through March 31). If the user entity's financial year ends on December 31, a nine-month gap exists. Management must obtain a formal Bridge Letter (or Gap Letter) signed by the cloud provider's executive management, certifying that no material changes or control failures have occurred in the cloud environment between the end of the SOC report period and the user entity's reporting date.