01 Cloud Compliance Fundamentals

Cloud computing changes the way organizations design, operate, secure, and govern technology.

It also changes how organizations approach compliance.

In traditional environments, an organization may directly own:

• Data centers.

• Servers.

• Networks.

• Storage.

• Physical security.

• Operating systems.

In cloud environments, many of these responsibilities are shared with cloud service providers.

This creates a different compliance model.

Instead of asking only:

Are our security controls implemented?

cloud compliance requires organizations to ask:

Who is responsible for this control?
        ↓
What does the cloud provider operate?
        ↓
What must the customer operate?
        ↓
Which controls are shared?
        ↓
What evidence proves each responsibility?
        ↓
Which legal, regulatory, contractual, and geographic requirements apply?

This lesson establishes the foundation for the rest of this cloud compliance module.

You will build on the ISO/IEC 27001 concepts from the previous module and extend them into cloud-specific areas such as:

• Shared responsibility.

• ISO/IEC 27017.

• ISO/IEC 27018.

• Cloud provider assurance.

• Multi-cloud governance.

• Data residency.

• Cloud auditing.

• Cloud risk management.

Learning Objectives

By the end of this lesson, you will be able to:

• Explain what cloud compliance means.

• Understand how cloud compliance differs from traditional compliance.

• Explain shared responsibility.

• Identify cloud customer and provider responsibilities.

• Understand control inheritance.

• Understand shared controls.

• Identify cloud-specific risk areas.

• Explain the role of ISO/IEC 27017.

• Explain the role of ISO/IEC 27018.

• Understand cloud provider assurance.

• Identify legal, regulatory, contractual, and customer requirements.

• Understand data residency and sovereignty considerations.

• Explain multi-cloud compliance challenges.

• Build a basic cloud compliance operating model.

• Understand the role of GRC professionals in cloud governance.

1. What Is Cloud Compliance?

Cloud compliance is the process of ensuring that cloud services, configurations, operations, data, and governance meet applicable:

• Laws.

• Regulations.

• Industry standards.

• Contracts.

• Internal policies.

• Customer requirements.

• Security frameworks.

A simple model is:

Cloud Environment
      ↓
Requirements
      ↓
Risks
      ↓
Controls
      ↓
Evidence
      ↓
Assurance

Cloud compliance should be integrated into cloud governance rather than treated as a separate audit activity.

2. Cloud Compliance Is More Than Certification

A cloud provider may hold:

ISO/IEC 27001

SOC Reports

PCI Certifications

Other Assurance Reports

but that does not automatically make the customer compliant.

The customer’s own responsibilities still need to be understood and managed.

For example:

Cloud Provider
→ Protects physical data center

Customer
→ Configures IAM

Customer
→ Configures network controls

Customer
→ Protects application

Customer
→ Manages data

Provider certification cannot replace customer control responsibilities.

3. Why Cloud Compliance Is Different

Traditional model:

Organization
      ↓
Owns Infrastructure
      ↓
Operates Controls
      ↓
Produces Evidence

Cloud model:

Organization
      ↓
Cloud Provider
      +
Customer
      ↓
Shared Responsibilities
      ↓
Combined Evidence

This creates more complex accountability.

4. Cloud Service Models

Compliance responsibilities vary depending on the cloud-service model.

The main models are:

IaaS

PaaS

SaaS

5. Infrastructure as a Service

In IaaS, the provider commonly manages:

• Data centers.

• Physical servers.

• Physical networking.

• Virtualization layer.

The customer commonly manages:

• Operating systems.

• Applications.

• IAM.

• Network configuration.

• Data.

• Security configuration.

Example:

Provider
→ Hardware
→ Facilities
→ Hypervisor

Customer
→ VM OS
→ Firewall Rules
→ IAM
→ Application
→ Data

6. Platform as a Service

In PaaS, the provider manages more of the technology stack.

Example:

Provider
→ Infrastructure
→ Operating System
→ Runtime
→ Managed Platform

Customer
→ Application
→ Identity
→ Configuration
→ Data

Customer responsibility decreases in some technical areas but does not disappear.

7. Software as a Service

In SaaS, the provider manages most technical infrastructure.

However, the customer may still be responsible for:

Users

Access

Configuration

Data Classification

Data Sharing

Retention

Vendor Governance

Example:

SaaS Provider
→ Application Infrastructure

Customer
→ User Access
→ Security Settings
→ Data
→ Business Usage

8. Shared Responsibility Model

The shared-responsibility model defines how responsibilities are divided between the cloud provider and the customer.

Conceptually:

Provider Responsibility
        +
Customer Responsibility
        +
Shared Responsibility
        =
Cloud Security & Compliance

This is one of the most important concepts in cloud governance.

9. Provider Responsibilities

Depending on the service model, the provider may be responsible for:

• Physical security.

• Facilities.

• Hardware.

• Hypervisor.

• Managed infrastructure.

• Service availability.

• Certain platform security controls.

The exact responsibility depends on the service.

10. Customer Responsibilities

The customer may be responsible for:

IAM

Data Classification

Configuration

Encryption Configuration

Network Policies

Security Monitoring

Application Security

User Management

Vendor Governance

These responsibilities remain even when the infrastructure is outsourced.

11. Shared Controls

Some controls involve both parties.

Example:

Business Continuity

Provider:

Infrastructure resilience

Customer:

Application architecture
Recovery procedures
Testing

Another example:

Logging

Provider:

Generates platform logs

Customer:

Enables logs
Collects logs
Monitors logs
Retains logs

12. Why Shared Controls Matter

Weak assumption:

The provider has a logging control, so we are covered.

Stronger analysis:

Provider creates logging capability
      ↓
Customer must enable it
      ↓
Customer must centralize logs
      ↓
Customer must monitor alerts

A provider capability is not always equivalent to an implemented customer control.

13. Control Ownership

Each cloud control should identify:

Provider

Customer

Shared

Example:

Control	Responsibility
Physical Data Center	Provider
IAM Configuration	Customer
Encryption Capability	Shared
Key Management	Customer / Shared
Application Security	Customer
Platform Availability	Shared

This becomes part of the cloud compliance model.

14. Control Inheritance

A customer may rely on controls operated by the cloud provider.

This is called control inheritance.

Example:

Physical Security
      ↓
Inherited From Cloud Provider

Evidence may include:

• ISO certificates.

• SOC reports.

• Assurance reports.

• Provider audit documentation.

15. Inherited Does Not Mean Ignored

Even when a control is inherited, the customer should understand:

What is inherited?

Which provider operates it?

What evidence supports it?

What limitations exist?

Which customer responsibilities remain?

This is critical for assurance.

16. Cloud Provider Assurance

Organizations should evaluate whether their cloud providers maintain appropriate security assurance.

Evidence may include:

ISO/IEC 27001 Certificate

ISO/IEC 27017 Coverage

ISO/IEC 27018 Coverage

SOC 1 Report

SOC 2 Report

Penetration Testing Summary

Security Documentation

The required evidence depends on risk and regulatory context.

17. Provider Assurance Is Risk Based

Not every vendor requires identical assurance.

Example:

Low-Risk SaaS
→ Basic Assessment

Critical Cloud Provider
→ Detailed Assurance Review

Factors include:

• Data sensitivity.

• Service criticality.

• Regulatory impact.

• Business dependency.

• Privileged access.

• Geographic processing.

18. ISO/IEC 27001 in Cloud Environments

ISO/IEC 27001 remains the foundation.

It provides the ISMS structure:

Context
      ↓
Risk Assessment
      ↓
Risk Treatment
      ↓
Controls
      ↓
Assurance
      ↓
Improvement

However, cloud introduces additional operational considerations.

This is where ISO/IEC 27017 and ISO/IEC 27018 become valuable.

19. ISO/IEC 27017

ISO/IEC 27017 provides cloud-security guidance based on information-security controls.

It helps clarify security responsibilities for:

Cloud Service Customers

Cloud Service Providers

It provides additional guidance relevant to cloud environments.

20. Why ISO/IEC 27017 Matters

ISO/IEC 27001 may identify a general control area such as access management.

ISO/IEC 27017 helps consider how that control should operate specifically in a cloud context.

Example:

ISO/IEC 27001
→ Access Control

ISO/IEC 27017
→ Cloud-specific responsibilities and implementation guidance

This helps GRC teams translate general controls into cloud operations.

21. ISO/IEC 27017 Focus Areas

Cloud-specific topics may include:

Cloud Responsibility

Virtual Environments

Cloud Configuration

Cloud Monitoring

Cloud Administration

Cloud Customer Isolation

Cloud Service Operations

Cloud Service Termination

The standard helps clarify expectations across provider and customer relationships.

22. ISO/IEC 27018

ISO/IEC 27018 focuses on the protection of personally identifiable information processed in public cloud services.

It is particularly relevant where cloud providers act as processors of personal information.

The focus includes:

Privacy Protection

PII Processing

Data Use

Disclosure

Deletion

Transparency

Cloud Provider Responsibilities

23. ISO 27017 vs ISO 27018

A simple way to understand the distinction:

ISO/IEC 27017
      ↓
Cloud Security

ISO/IEC 27018
      ↓
Privacy Protection in Public Cloud

They complement ISO/IEC 27001 rather than replace it.

24. Cloud Compliance Architecture

A mature cloud compliance model may look like:

Enterprise Requirements
        ↓
Cloud Governance
        ↓
Cloud Risk Assessment
        ↓
Shared Responsibility Matrix
        ↓
Control Framework
        ↓
Provider Assurance
        ↓
Cloud Configuration
        ↓
Evidence
        ↓
Monitoring
        ↓
Audit

25. Cloud Governance

Cloud governance establishes:

Who can use cloud?

Which services are approved?

Where data may be stored?

How cloud is configured?

Who owns controls?

How evidence is collected?

Without governance, cloud compliance becomes reactive.

26. Cloud Governance Policies

Organizations may establish policies covering:

• Cloud acquisition.

• Approved providers.

• Cloud security.

• IAM.

• Data residency.

• Encryption.

• Logging.

• Cloud architecture.

• Vendor risk.

These provide consistent direction.

27. Cloud Service Approval

Before adopting a cloud service:

Business Request
      ↓
Security Review
      ↓
Risk Assessment
      ↓
Privacy Review
      ↓
Contract Review
      ↓
Approval

This prevents uncontrolled SaaS and cloud usage.

28. Shadow IT

One of the major cloud-compliance challenges is shadow IT.

Example:

Employee
      ↓
Creates SaaS Account
      ↓
Uploads Customer Data
      ↓
No Security Review

Potential impacts:

• Data leakage.

• Privacy violations.

• Unsupported contracts.

• Missing evidence.

• Unknown third-party risk.

29. Cloud Inventory

A cloud compliance program should maintain an inventory of:

Cloud Accounts

Cloud Subscriptions

SaaS Services

Cloud Providers

Data Locations

Service Owners

You cannot govern cloud services you do not know exist.

30. Cloud Account Governance

Cloud accounts or subscriptions should have:

• Owners.

• Purpose.

• Environment classification.

• Security baseline.

• Logging.

• Billing ownership.

• Lifecycle controls.

Example:

AWS Account
      ↓
Production
      ↓
Owner: Cloud Operations

31. Cloud Configuration Compliance

Cloud environments are highly configurable.

Configuration risk may include:

Public Storage

Open Security Groups

Unencrypted Data

Excessive IAM Permissions

Disabled Logging

Cloud compliance should therefore include configuration monitoring.

32. Secure Configuration Baselines

Define baseline requirements.

Example:

Storage must not be public.

Encryption must be enabled.

MFA required for privileged users.

Administrative logging enabled.

Public management ports prohibited.

These become measurable controls.

33. Infrastructure as Code

Modern organizations use:

Terraform

CloudFormation

Bicep

Other IaC

This creates an opportunity to embed compliance before deployment.

Example:

Code
      ↓
Security Check
      ↓
Policy Validation
      ↓
Deployment

34. Policy as Code

Policy-as-code can automatically detect or block noncompliant infrastructure.

Example:

Deployment Request
      ↓
Policy Check
      ↓
Compliant?
      │
      ├── Yes → Deploy
      └── No → Block

This shifts compliance earlier in the lifecycle.

35. Continuous Cloud Compliance

Traditional audit:

Annual Review

Modern cloud compliance:

Continuous Monitoring

Because cloud resources change constantly.

Examples:

• New storage bucket.

• New VM.

• New API.

• New IAM role.

• New SaaS integration.

Static annual evidence can quickly become outdated.

36. Cloud Security Posture Management

Cloud security posture management tools may help identify:

Misconfigurations

Exposed Services

Missing Encryption

IAM Weaknesses

Compliance Violations

These tools can support continuous assurance.

They do not replace governance or risk analysis.

37. Cloud Identity Governance

Identity is one of the most important cloud control areas.

Cloud IAM should address:

Authentication

Authorization

Privileged Access

Service Accounts

Federation

Access Reviews

Lifecycle Management

Weak IAM can undermine otherwise strong cloud controls.

38. Human Identity vs Workload Identity

Cloud environments include:

Human Identities

Applications

Service Accounts

Managed Identities

API Credentials

All must be governed.

Example:

Application
      ↓
Service Identity
      ↓
Cloud Resource Access

These identities should follow least privilege.

39. Privileged Cloud Access

Privileged access should be tightly controlled.

Example:

User
      ↓
Strong Authentication
      ↓
Approval
      ↓
Temporary Privilege
      ↓
Logging
      ↓
Monitoring

Long-lived administrator access creates unnecessary risk.

40. Cloud Logging

A cloud compliance program should determine:

Which logs are required?

Who enables them?

Where are they stored?

How long are they retained?

Who monitors them?

Examples may include:

• Administrative activity.

• Authentication.

• Network activity.

• Storage access.

• Application events.

41. Cloud Evidence

Useful cloud evidence may include:

IAM Reports

Configuration Exports

Security Posture Reports

Cloud Audit Logs

Encryption Configuration

Backup Reports

Network Configuration

Policy-as-Code Results

Automated evidence can improve audit readiness.

42. Cloud Data Governance

Cloud compliance should understand:

What data exists?

Where is it stored?

Who accesses it?

Where is it processed?

Who owns it?

How long is it retained?

This becomes particularly important for privacy and residency requirements.

43. Data Classification

Data should be classified.

Example:

Public

Internal

Confidential

Restricted

Cloud controls can then be based on classification.

Example:

Restricted
      ↓
Encryption
Restricted Access
Approved Region
Enhanced Monitoring

44. Data Residency

Data residency refers to where data is physically or logically stored or processed.

Organizations may need to know:

Country

Cloud Region

Backup Region

Processing Location

Support Location

These factors may affect legal and contractual compliance.

45. Data Sovereignty

Data sovereignty concerns how data is subject to the laws of relevant jurisdictions.

It can be more complex than simply knowing which cloud region is selected.

Consider:

Data Location

Organization Location

Cloud Provider

Legal Jurisdiction

Data Access

GRC should work with legal and privacy teams on these questions.

46. Cross-Border Data Transfers

Cloud services may move or process information across jurisdictions.

Organizations should understand:

• Primary storage.

• Backup locations.

• Support access.

• Subprocessors.

• Data-transfer mechanisms.

• Contract requirements.

This is particularly important for privacy.

47. Encryption

Cloud compliance commonly requires:

Encryption at Rest

Encryption in Transit

But also consider:

Who owns the key?

Who can access the key?

How is it rotated?

Where is it stored?

Encryption governance is more than checking a checkbox.

48. Provider-Managed Keys

Example:

Cloud Provider
      ↓
Manages Encryption Key

This may be sufficient for some data.

For higher sensitivity, stronger customer control may be required.

49. Customer-Managed Keys

Example:

Customer
      ↓
Controls Key
      ↓
Cloud Service Uses Key

This provides greater governance but introduces additional operational responsibility.

50. Cloud Key Management Risk

Potential issues include:

• Excessive key access.

• Key deletion.

• Weak rotation.

• Poor backup.

• Cross-region restrictions.

Key-management controls should match data risk.

51. Cloud Vendor Risk

Cloud compliance includes Third-Party Risk Management.

Evaluate:

Security

Privacy

Availability

Subprocessors

Data Location

Incident Notification

Exit Strategy

The provider relationship should be managed throughout its lifecycle.

52. Cloud Contract Requirements

Contracts may include:

Security Responsibilities

Breach Notification

Audit Rights

Data Location

Data Deletion

Subprocessor Notification

Availability Commitments

These requirements should map into the compliance framework.

53. Cloud Provider Exit

Organizations should plan what happens when a provider relationship ends.

Questions include:

How do we export data?

How do we delete data?

How do we revoke access?

How do we validate deletion?

How do we transition service?

Cloud exit is part of lifecycle governance.

54. Vendor Lock-In

Compliance and operational risk may increase when migration is extremely difficult.

Consider:

Data Portability

Proprietary Services

Exit Cost

Recovery Options

This can become an enterprise risk.

55. Availability and Resilience

Cloud availability is a shared responsibility.

Provider may provide:

Regional Infrastructure

Availability Zones

Customer must design:

Architecture

Redundancy

Failover

Recovery

Using the cloud does not automatically create resilience.

56. Backup Responsibility

Depending on the service:

Provider:
Provides backup capability

Customer:
Configures backup

Customer:
Defines retention

Customer:
Tests recovery

This distinction is critical during audits.

57. Cloud Incident Response

Cloud incidents require understanding the shared-response model.

Example:

Cloud Provider Incident
      ↓
Provider Investigates Infrastructure

Customer
      ↓
Evaluates Business Impact

Customer
      ↓
Responds to Accounts / Data / Applications

Contracts should define communication expectations.

58. Cloud Forensics

Cloud environments can make evidence collection different.

Potential sources include:

Cloud Audit Logs

Identity Logs

Network Flow Logs

Object Access Logs

Provider Support Records

Organizations should determine in advance which logs are available.

59. Privacy in Cloud

Cloud privacy governance should understand:

Personal Data

Processing Purpose

Data Location

Subprocessors

Retention

Deletion

Access

ISO/IEC 27018 provides useful guidance for public cloud PII processing.

60. Privacy Roles

Organizations should understand:

Controller

Processor

Subprocessor

roles where applicable.

The exact legal interpretation depends on the relevant privacy regime.

61. PII Inventory

A cloud privacy program may maintain:

Data	Cloud Service	Region	Owner
Customer Profiles	SaaS Platform	EU	Product
Employee Records	HR SaaS	EU	HR
Support Tickets	Support SaaS	US	Support

This supports privacy analysis.

62. Data Deletion

Cloud services should support appropriate deletion requirements.

Questions include:

Can data be deleted?

Are backups included?

How long until deletion completes?

How is deletion verified?

These may become important contractual controls.

63. Multi-Cloud Governance

Many organizations use:

AWS

Azure

Google Cloud

Multiple SaaS Providers

This creates governance complexity.

Each platform may use different terminology, services, and security controls.

64. Multi-Cloud Control Consistency

The organization should define common enterprise requirements.

Example:

Enterprise Requirement:
Privileged MFA

Then map:

AWS
→ Implementation A

Azure
→ Implementation B

Google Cloud
→ Implementation C

The control objective stays consistent.

65. Common Cloud Control Framework

A scalable model is:

Enterprise Cloud Control
        ↓
AWS Mapping
        ↓
Azure Mapping
        ↓
GCP Mapping
        ↓
SaaS Mapping

This avoids duplicate governance.

66. Multi-Cloud Inventory

Maintain:

Account

Subscription

Project

Owner

Environment

Region

Data Classification

Criticality

Without inventory, multi-cloud governance becomes difficult.

67. Cloud Compliance Mapping

A mature organization may map one control across:

ISO/IEC 27001

ISO/IEC 27017

ISO/IEC 27018

SOC 2

PCI DSS

Internal Cloud Policy

This reduces duplication.

68. Example Common Control

Enterprise control:

All privileged human access to production cloud environments must use approved multi-factor authentication.

This may support:

ISO Controls

Cloud Security Requirements

SOC 2

PCI DSS

Customer Contracts

One control can satisfy several obligations.

69. Compliance Does Not Equal Security

An environment can pass a compliance check and still have risk.

Example:

Encryption Enabled

but:

Everyone Has Administrator Access

Compliance should support risk management rather than replace it.

70. Security Does Not Automatically Equal Compliance

A cloud environment may be technically secure but still fail requirements.

Example:

Data well protected

but:

Stored in prohibited region

This creates compliance risk.

71. Cloud Risk Categories

Common categories include:

Identity Risk

Configuration Risk

Data Exposure

Availability

Third-Party Risk

Privacy

Residency

Supply Chain

Logging

Application Security

These should appear in the cloud risk register.

72. Example Cloud Risk

There is a risk that cloud storage may be configured for public access, resulting in unauthorized disclosure of confidential customer information.

Possible controls:

Secure Baseline

Policy as Code

CSPM

Encryption

Monitoring

73. Cloud Risk Ownership

Risk owners may include:

CTO

CISO

Cloud Platform Owner

Business Owner

GRC should facilitate but not own every technical risk.

74. Cloud Control Owners

Example:

Control	Owner
IAM	Identity Team
Cloud Network	Cloud Engineering
Logging	SOC
Data Protection	Security / Data
Vendor Assurance	GRC
Backup	Platform Operations

Ownership should reflect actual operation.

75. Cloud Evidence Ownership

For each control identify:

Control Owner

Evidence Owner

Repository

Example:

Cloud Logging
      ↓
Owner: SOC
      ↓
Evidence: SIEM

76. Cloud Compliance Dashboard

Useful metrics may include:

Cloud Accounts Inventoried

MFA Coverage

Encryption Coverage

Public Resource Count

Logging Coverage

Critical Configuration Findings

Approved SaaS Coverage

Vendor Reviews Current

Metrics should support risk decisions.

77. Example KRI

KRI:
Number of production storage resources
with public exposure

Target:

0

78. Example KPI

KPI:
Percentage of production cloud accounts
with centralized administrative logging enabled

Target:

100%

79. Cloud Compliance Evidence Model

A strong model is:

Requirement
      ↓
Control
      ↓
Cloud Configuration
      ↓
Automated Evidence
      ↓
Exception
      ↓
Remediation

This provides continuous traceability.

80. Cloud Exceptions

Example:

Control:
Encryption required

Exception:
Legacy workload

The exception should include:

Risk

Business Justification

Compensating Control

Approver

Expiration

Exceptions should not become permanent invisible gaps.

81. Cloud Compliance Audit

Auditors may examine:

Cloud Inventory

Responsibility Matrix

Provider Assurance

Cloud Configurations

Risk Register

Security Baselines

Evidence

Exceptions

They may also inspect specific cloud resources.

82. Cloud Audit Walkthrough

Example:

Auditor selects:

Production AWS Account

Then asks:

Who owns it?

What baseline applies?

Is MFA enabled?

Is logging enabled?

Where is data stored?

Which provider controls are inherited?

What evidence exists?

A mature environment should answer these questions quickly.

83. Provider Evidence Review

When relying on provider controls, GRC should understand:

Report Scope

Report Period

Services Covered

Exceptions

Subservice Organizations

Customer Responsibilities

Do not simply store the report.

Analyze it.

84. Customer Responsibilities

Provider reports often identify customer responsibilities.

Example:

Provider:
Secure physical infrastructure

Customer:
Secure administrator accounts

These customer responsibilities should map into the customer’s own control library.

85. Cloud Compliance Operating Model

A practical operating model is:

Business Requirement
      ↓
Cloud Service
      ↓
Risk Assessment
      ↓
Responsibility Matrix
      ↓
Control Mapping
      ↓
Provider Assurance
      ↓
Customer Controls
      ↓
Evidence
      ↓
Continuous Monitoring
      ↓
Audit

86. Cloud Compliance Lifecycle

Cloud Request
      ↓
Due Diligence
      ↓
Risk Review
      ↓
Approval
      ↓
Secure Configuration
      ↓
Monitoring
      ↓
Reassessment
      ↓
Offboarding

Compliance should cover the full lifecycle.

87. Cloud Onboarding

Before approving a service, check:

• Security.

• Privacy.

• Data residency.

• Vendor assurance.

• Contract.

• IAM.

• Logging.

• Exit capability.

88. Cloud Operation

During use:

Monitor Configuration

Review Access

Review Provider Assurance

Track Incidents

Track Changes

Review Risks

89. Cloud Offboarding

When leaving:

Export Data

Delete Data

Revoke Access

Disable Integrations

Close Accounts

Verify Deletion

Offboarding is often overlooked.

90. Common Cloud Compliance Mistakes

Mistake 1 — Assuming Provider Certification Covers the Customer

It does not.

Mistake 2 — No Shared-Responsibility Matrix

Accountability becomes unclear.

Mistake 3 — Cloud Resources Not Inventoried

Shadow cloud services remain unmanaged.

Mistake 4 — No Data Location Awareness

Residency requirements may be violated.

Mistake 5 — Provider Reports Collected but Not Reviewed

Assurance becomes a checkbox.

Mistake 6 — Logging Capability Exists but Is Disabled

Provider capability is not implementation.

Mistake 7 — Multi-Cloud Standards Differ by Platform

Controls become inconsistent.

Mistake 8 — SaaS Treated as Low Risk by Default

Some SaaS platforms process critical information.

Mistake 9 — Cloud Compliance Reviewed Annually Only

Cloud changes too rapidly.

Mistake 10 — No Exit Strategy

Data and dependency risk remain unresolved.

91. Weak Cloud Compliance Model

Cloud Provider Certified
      ↓
Customer Assumes Compliance

This creates blind spots.

92. Strong Cloud Compliance Model

Provider Assurance
      +
Customer Responsibilities
      +
Shared Controls
      +
Risk Management
      +
Continuous Evidence
      =
Cloud Compliance

93. Practical Activity — Build Cloud Service Inventory

Create:

01 Cloud Service Inventory

Use:

Service	Provider	Owner	Data	Region	Criticality

Include at least:

• Cloud infrastructure.

• Identity provider.

• Source control.

• HR SaaS.

• Support SaaS.

94. Practical Activity — Build Responsibility Matrix

Create:

02 Cloud Shared Responsibility Matrix

Use:

Control Area	Provider	Customer	Shared

Cover:

Physical Security

IAM

Network Security

Encryption

Logging

Backup

Incident Response

Business Continuity

95. Practical Activity — Build Provider Assurance Register

Create:

03 Cloud Provider Assurance Register

Fields:

Provider

Service

Certification / Report

Scope

Period

Review Owner

Findings

Next Review

96. Practical Activity — Build Cloud Requirements Register

Create:

04 Cloud Compliance Requirements Register

Include:

Requirement

Source

Cloud Service

Data

Region

Control

Owner

97. Practical Activity — Build Cloud Risk Register

Create:

05 Cloud Risk Register

Include at least 10 risks across:

Identity

Configuration

Data

Availability

Vendor

Privacy

Residency

Monitoring

Application Security

Exit

98. Practical Activity — Build Common Cloud Controls

Create at least 10 enterprise controls such as:

CLOUD-001
Cloud Account Inventory

CLOUD-002
Privileged MFA

CLOUD-003
Centralized Logging

CLOUD-004
Encryption

CLOUD-005
Public Exposure Prevention

CLOUD-006
Vendor Assurance Review

CLOUD-007
Data Residency Validation

CLOUD-008
Backup Recovery Testing

CLOUD-009
Cloud Configuration Monitoring

CLOUD-010
Cloud Offboarding

99. Practical Activity — Build Cloud Evidence Matrix

Create:

06 Cloud Evidence Matrix

Use:

Control	Evidence	Source	Owner	Frequency

100. Cloud Compliance Checklist

Before considering a cloud environment governed:

• Cloud services inventoried.

• Business owners identified.

• Data identified.

• Data classifications known.

• Regions documented.

• Shared responsibilities documented.

• Provider assurance reviewed.

• Customer controls identified.

• Shared controls identified.

• IAM requirements established.

• Encryption requirements established.

• Logging requirements established.

• Backup requirements established.

• Cloud configuration baselines established.

• Vendor requirements established.

• Residency requirements reviewed.

• Privacy obligations reviewed.

• Exceptions tracked.

• Evidence mapped.

• Continuous monitoring established.

• Exit requirements documented.

101. GRC Analyst Responsibilities

A GRC professional supporting cloud compliance may:

• Maintain cloud requirements.

• Facilitate cloud risk assessments.

• Review provider assurance.

• Build shared-responsibility matrices.

• Map provider and customer controls.

• Review cloud contract requirements.

• Track data residency.

• Maintain cloud control mappings.

• Coordinate evidence.

• Track cloud exceptions.

• Support cloud audits.

• Coordinate multi-cloud governance.

• Maintain ISO/IEC 27017 mappings.

• Maintain ISO/IEC 27018 privacy mappings.

This role sits between:

Business

Legal

Privacy

Cloud Engineering

Security

Providers

Audit

102. Cloud Compliance Maturity

Level 1 — Ad Hoc

Cloud adopted independently

Little inventory

Provider certificates stored

Level 2 — Documented

Inventory

Policies

Vendor Reviews

Level 3 — Governed

Responsibility Matrix

Risk Assessment

Control Ownership

Level 4 — Automated

Policy as Code

Continuous Monitoring

Automated Evidence

Level 5 — Integrated

Multi-Cloud Controls

Continuous Assurance

Common Control Framework

103. Cloud Compliance Mindset

When assessing any cloud service, ask:

What business service uses it?

What information is processed?

Where is that information located?

Which requirements apply?

What does the provider operate?

What does the customer operate?

Which controls are shared?

Which controls are inherited?

What evidence supports provider controls?

What evidence supports customer controls?

How do we know configuration remains compliant?

What happens if the service changes?

What happens when we leave the provider?

If these questions can be answered, cloud compliance becomes manageable rather than ambiguous.

Key Takeaways

• Cloud compliance combines requirements, cloud risk, shared responsibility, controls, evidence, and assurance.

• Cloud-provider certification does not automatically make the customer compliant.

• Responsibility varies across IaaS, PaaS, and SaaS.

• Provider, customer, inherited, and shared controls should be clearly understood.

• ISO/IEC 27001 remains the ISMS foundation for cloud environments.

• ISO/IEC 27017 extends security guidance into cloud-specific scenarios.

• ISO/IEC 27018 focuses on protecting PII in public cloud environments.

• Cloud compliance requires an inventory of cloud services, owners, data, and locations.

• Data residency and sovereignty can materially affect compliance.

• Cloud provider assurance should be reviewed rather than simply collected.

• Cloud controls should increasingly support continuous monitoring and automated evidence.

• Multi-cloud environments benefit from a common enterprise cloud-control model.

• GRC plays a central role in connecting cloud engineering, legal, privacy, vendor assurance, security, and audit.

Knowledge Check

Before continuing, make sure you can answer:

1. What is cloud compliance?

2. Why does cloud-provider certification not automatically make a customer compliant?

3. What is the shared-responsibility model?

4. How do IaaS, PaaS, and SaaS affect customer responsibility?

5. What is an inherited control?

6. What is a shared control?

7. Why should provider assurance reports be reviewed?

8. What is ISO/IEC 27017?

9. What is ISO/IEC 27018?

10. How are ISO/IEC 27017 and ISO/IEC 27018 different?

11. What is data residency?

12. What is data sovereignty?

13. Why is cloud inventory important?

14. What is shadow IT?

15. Why is IAM critical in cloud compliance?

16. How can policy-as-code support compliance?

17. Why is continuous monitoring valuable?

18. What challenges does multi-cloud create?

19. What should be considered during cloud offboarding?

20. What role does GRC play in cloud compliance?

What’s Next?

➡️ Next: 02 — Shared Responsibility Model

In the next lesson, you will go deeper into one of the most important concepts in cloud security and compliance: who is responsible for what.

You will learn how to build responsibility models across:

Cloud Provider
      ↓
Infrastructure Responsibilities

Customer
      ↓
Configuration & Data Responsibilities

Shared
      ↓
Joint Security Responsibilities

Inherited
      ↓
Provider-Operated Controls

You will also learn how responsibility changes between IaaS, PaaS, SaaS, and multi-cloud environments, and how to translate shared responsibility into a practical Cloud Responsibility Matrix, Control Ownership Model, Provider Assurance Map, and Audit Evidence Model.