Lab 01 — Build a Cloud Compliance Responsibility Matrix

Mission Information

Field	Details
Lab Type	Cloud Compliance / Shared Responsibility
Difficulty	Intermediate
Estimated Time	3–4 Hours
Primary Role	GRC Analyst / Cloud Compliance Analyst
Environment	Simulated Multi-Cloud Enterprise
Primary Standards	ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018
Primary Deliverable	Cloud Compliance Responsibility Matrix

Mission Scenario

You have joined CloudNova Technologies, a fictional enterprise operating several cloud services across different providers.

CloudNova uses:

AWS
→ Production workloads

Azure
→ Enterprise identity and collaboration

Google Cloud
→ Data analytics

SaaS
→ HR, CRM, Support, Source Control

The organization recently completed a cloud compliance review.

Management discovered a recurring problem:

Teams know which cloud services they use, but they do not clearly understand who is responsible for individual security and compliance controls.

For example:

Cloud Provider:
Provides logging capability

Cloud Team:
Assumes provider monitors everything

SOC:
Assumes Cloud Team forwards logs

Result:
Logging Gap

Another example:

Cloud Provider:
Provides backup functionality

Application Team:
Assumes backups are automatic

Result:
No recovery testing

Senior management has asked the GRC team to build a formal Cloud Compliance Responsibility Matrix.

Your mission is to determine:

What does the provider own?

What does the customer own?

What is shared?

What is inherited?

Who owns the customer's responsibility?

What evidence proves each side?

Where are responsibility gaps?

Mission Objectives

By completing this lab, you will be able to:

• Inventory enterprise cloud services.

• Identify IaaS, PaaS, and SaaS service models.

• Analyze shared-responsibility boundaries.

• Identify provider responsibilities.

• Identify customer responsibilities.

• Identify shared controls.

• Identify inherited controls.

• Assign internal control owners.

• Identify provider assurance evidence.

• Identify customer operational evidence.

• Build responsibility matrices.

• Identify responsibility gaps.

• Map gaps to cloud risks.

• Develop remediation actions.

• Build an executive responsibility summary.

• Prepare responsibility evidence for audit.

Lab Architecture

You will build:

Cloud Service Inventory
        ↓
Service Model Classification
        ↓
Provider Responsibility
        ↓
Customer Responsibility
        ↓
Shared / Inherited Controls
        ↓
Internal Ownership
        ↓
Provider Evidence
        ↓
Customer Evidence
        ↓
Responsibility Gap Assessment
        ↓
Remediation

Lab Deliverables

Create the following artifacts:

Cloud-Compliance-Lab01/
│
├── 01-Cloud-Service-Inventory.md
├── 02-IaaS-Responsibility-Matrix.md
├── 03-PaaS-Responsibility-Matrix.md
├── 04-SaaS-Responsibility-Matrix.md
├── 05-Enterprise-Control-Responsibility-Register.md
├── 06-Provider-Responsibility-Map.md
├── 07-Customer-Control-Register.md
├── 08-Shared-Control-Register.md
├── 09-Inherited-Control-Evidence-Map.md
├── 10-Responsibility-Gap-Register.md
└── 11-Executive-Responsibility-Summary.md

Part 1 — Understand the Enterprise Environment

Step 1 — Review the Cloud Architecture

CloudNova operates the following environment:

                           CloudNova
                               │
           ┌───────────────────┼───────────────────┐
           │                   │                   │
           ▼                   ▼                   ▼
          AWS                Azure                GCP
           │                   │                   │
     Production App       Identity / M365     Data Analytics
           │
     ┌─────┼─────┐
     ▼     ▼     ▼
   EC2    RDS    S3

                           SaaS
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
            HR SaaS       CRM SaaS      Support SaaS

You will assess responsibility across all four areas.

Part 2 — Build the Cloud Service Inventory

Step 2 — Create the Inventory

Create:

01-Cloud-Service-Inventory.md

Use:

ID	Provider	Service	Service Model	Owner	Data	Criticality
CS-001	AWS	EC2	IaaS	Cloud Ops	Internal / Customer	High
CS-002	AWS	RDS	PaaS	App Team	Customer PII	Critical
CS-003	AWS	S3	PaaS	Data Team	Customer Data	Critical
CS-004	Azure	Microsoft 365	SaaS	IT	Employee Data	High
CS-005	Azure	Entra ID	SaaS / Managed Identity	IAM	Identity Data	Critical
CS-006	GCP	BigQuery	PaaS	Data Team	Analytics	High
CS-007	SaaS Provider	HR Platform	SaaS	HR	Employee PII	High
CS-008	SaaS Provider	CRM	SaaS	Sales	Customer Data	High

Add at least 10 services.

3. Classify the Service Model

For each cloud service determine:

IaaS

PaaS

SaaS

Remember:

IaaS
→ Customer manages more

PaaS
→ Provider manages more

SaaS
→ Provider manages most platform components

Do not classify the provider itself.

Classify the specific service.

4. Identify Business Owner

Every service should have a business owner.

Example:

HR SaaS
→ HR Director

Production AWS
→ CTO / Application Owner

Identity
→ IAM Director

5. Identify Technical Owner

Add:

Technical Owner

where appropriate.

Example:

AWS EC2
→ Cloud Operations

RDS
→ Database Team

M365
→ IT Operations

6. Identify Data

Record:

Public

Internal

Confidential

Restricted / PII

This will influence responsibility and control expectations.

Part 3 — Build the IaaS Responsibility Matrix

Step 7 — Create

02-IaaS-Responsibility-Matrix.md

Assume AWS EC2 supports the primary production application.

Use:

Control Area	Provider Responsibility	Customer Responsibility	Type

8. Physical Facility

Provider:

Data Center

Physical Access

Environmental Controls

Customer:

Review Provider Assurance

Responsibility:

Inherited

9. Physical Hardware

Provider:

Servers

Storage Hardware

Network Hardware

Customer:

Review Assurance

Responsibility:

Inherited

10. Hypervisor

Provider:

Operate Hypervisor

Patch Hypervisor

Maintain Tenant Isolation

Customer:

Review Assurance

Responsibility:

Inherited

11. Guest Operating System

Provider:

No direct management

Customer:

Patch OS

Harden OS

Configure Users

Install Security Agents

Responsibility:

Customer

12. Application

Provider:

No application responsibility

Customer:

Secure Coding

Patching

Authentication

Authorization

Testing

Responsibility:

Customer

13. Logical Network Security

Provider:

Provides virtual network capability

Customer:

Configures:

Security Groups

Routes

Firewalls

Subnets

Responsibility:

Shared

14. Identity

Provider:

Provides IAM capability

Customer:

Defines users

Roles

MFA

Permissions

Access Reviews

Responsibility:

Shared

15. Logging

Provider:

Provides cloud audit logging capability

Customer:

Enables logging

Centralizes logs

Defines retention

Monitors alerts

Responsibility:

Shared

16. Data

Provider:

Protects underlying storage infrastructure

Customer:

Classifies data

Configures permissions

Defines retention

Protects application access

Responsibility:

Shared

17. Backup

Provider:

Provides backup capability

Customer:

Enables backups

Defines retention

Tests recovery

Responsibility:

Shared

18. Complete IaaS Matrix

Include at least:

Physical Security

Hardware

Hypervisor

Guest OS

IAM

Network

Application

Data

Encryption

Logging

Monitoring

Backup

Recovery

Incident Response

Part 4 — Build the PaaS Responsibility Matrix

Step 19 — Create

03-PaaS-Responsibility-Matrix.md

Use AWS RDS or GCP BigQuery as your example.

20. Managed Operating System

Provider:

OS Patching

Platform Maintenance

Customer:

No direct OS management

Responsibility:

Inherited / Provider

21. Database Engine

Provider:

Maintains database platform

Customer:

Configures database options

Users

Permissions

Security Parameters

Responsibility:

Shared

22. Network Exposure

Provider:

Provides network controls

Customer:

Configures private/public access

Firewall Rules

Allowed Networks

Responsibility:

Shared

23. Database Users

Customer responsibility:

Identity

Roles

Least Privilege

Access Review

Responsibility:

Customer

24. Data Protection

Provider:

Provides encryption capability

Customer:

Configures encryption options

Controls key model

Controls access

Responsibility:

Shared

25. Backup

Provider:

Provides managed backup service

Customer:

Configures retention

Recovery requirements

Restore testing

Responsibility:

Shared

26. Logging

Provider:

Generates database / platform logs

Customer:

Enables audit logging

Exports to SIEM

Monitors events

Responsibility:

Shared

Part 5 — Build the SaaS Responsibility Matrix

Step 27 — Create

04-SaaS-Responsibility-Matrix.md

Use an HR SaaS platform.

28. Application Infrastructure

Provider:

Application

Runtime

OS

Infrastructure

Patching

Customer:

Review Assurance

Responsibility:

Inherited

29. User Accounts

Provider:

Provides user-management capability

Customer:

Creates users

Removes users

Assigns roles

Reviews access

Responsibility:

Customer

30. MFA

Provider:

Provides MFA capability

Customer:

Enables and enforces MFA

Responsibility:

Shared

31. Data Sharing

Provider:

Provides sharing functionality

Customer:

Determines who can share

Configures external sharing

Monitors use

Responsibility:

Customer

32. Data Retention

Provider:

Provides retention capability

Customer:

Defines retention

Configures policy

Validates implementation

Responsibility:

Shared

33. Data Deletion

Provider:

Executes backend deletion process

Customer:

Initiates deletion

Determines when required

Validates completion

Responsibility:

Shared

34. SaaS Logging

Provider:

Provides audit-log capability

Customer:

Enables / exports logs

Reviews events

Responsibility:

Shared

35. SaaS Incident Response

Provider:

Responds to provider security incidents

Customer:

Assesses customer impact

Handles business response

Performs notification obligations

Responsibility:

Shared

Part 6 — Build the Enterprise Responsibility Register

Step 36 — Create

05-Enterprise-Control-Responsibility-Register.md

Use:

Control ID	Control	Service	Responsibility Type	Customer Owner	Provider Evidence	Customer Evidence

37. Control Types

Use:

Provider

Customer

Shared

Inherited

Keep these values consistent.

38. Example — Physical Security

Control:
PHY-001

Service:
AWS Production

Responsibility:
Inherited

Customer owner:

GRC / Vendor Risk

Provider evidence:

ISO Certificate

SOC Report

Customer evidence:

Provider Assurance Review

39. Example — Privileged MFA

Control:
IAM-002

Responsibility:

Shared

Provider:

Provides MFA capability

Customer:

Enforces MFA

Customer owner:

IAM Manager

Customer evidence:

MFA Coverage Report

40. Example — Central Logging

Control:
LOG-001

Responsibility:

Shared

Provider:

Generates audit events

Customer:

Enables and centralizes logs

Owner:

SOC Manager

Part 7 — Build the Provider Responsibility Map

Step 41 — Create

06-Provider-Responsibility-Map.md

Group provider responsibilities into:

Physical Security

Hardware

Virtualization

Managed Platform

Provider IAM

Provider Monitoring

Provider Incident Response

Provider Resilience

Provider Privacy

Data Deletion

42. Example Provider Map

Area	Provider Responsibility	Evidence
Physical Security	Data-center controls	SOC / ISO
Hypervisor	Secure virtualization	Assurance Report
Provider IAM	Admin access governance	SOC Report
Availability	Infrastructure resilience	SLA / Assurance
Incident Response	Provider incidents	Security Documentation
Privacy	Provider PII processing	DPA / ISO 27018

Part 8 — Build the Customer Control Register

Step 43 — Create

07-Customer-Control-Register.md

Include controls primarily owned by CloudNova.

Example:

IAM-001
Identity Lifecycle

IAM-002
Privileged MFA

IAM-003
Access Review

NET-001
Cloud Network Segmentation

CFG-001
Secure Configuration

LOG-001
Centralized Logging

DATA-001
Encryption

BCK-001
Backup Configuration

RES-001
Approved Region

IR-001
Cloud Incident Response

44. Define Customer Control Statement

Example:

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

45. Add Owner

Example:

Owner:
IAM Director

46. Add Frequency

Example:

Continuous

47. Add Evidence

Example:

MFA Coverage Report

Identity Configuration

Exception Register

Part 9 — Build the Shared Control Register

Step 48 — Create

08-Shared-Control-Register.md

Use:

Control	Provider Activity	Customer Activity	Customer Owner	Evidence

49. Example — Encryption

Provider:

Provides encryption service

Customer:

Enables encryption

Selects key model

Configures access

Owner:

Security Architecture

50. Example — Backup

Provider:

Provides backup capability

Customer:

Configures backups

Sets retention

Tests recovery

Owner:

Platform Operations

51. Example — Incident Response

Provider:

Handles provider infrastructure incident

Customer:

Handles account, application, and data impact

Owner:

Security Operations

52. Example — Data Residency

Provider:

Provides regional deployment capability

Customer:

Selects approved region

Owner:

Cloud Governance

Part 10 — Build the Inherited Control Evidence Map

Step 53 — Create

09-Inherited-Control-Evidence-Map.md

Use:

Inherited Control	Provider	Evidence	Scope	Reviewer	Review Frequency

54. Physical Security

Evidence may include:

ISO/IEC 27001 Certificate

SOC 2 Report

Provider Assurance

55. Virtualization

Evidence may include:

SOC Report

Security Architecture

Independent Audit

56. Provider Personnel Security

Evidence:

SOC Report

ISO Assurance

57. Provider Resilience

Evidence:

SLA

SOC Report

BCP Assurance

Provider Architecture

58. Evidence Scope Review

For each inherited control ask:

Does evidence cover:

Correct service?

Correct region?

Correct entity?

Current period?

Part 11 — Identify Responsibility Gaps

Step 59 — Create

10-Responsibility-Gap-Register.md

Use:

Gap ID	Service	Control	Gap	Risk	Owner	Action

60. Gap Scenario 1 — Logging

Current situation:

AWS provides logging capability.

CloudNova:

3 production accounts
not connected to SIEM.

Gap:

Shared logging responsibility has not been fully implemented by the customer.

Risk:

Unauthorized administrative activity
may not be detected.

61. Gap Scenario 2 — Backup

Provider:

Backup capability available

Customer:

Backups enabled
but never recovery tested

Gap:

Customer recovery responsibility is not operating.

Risk:

Backup may not be recoverable
during an incident.

62. Gap Scenario 3 — SaaS MFA

Provider:

MFA supported

Customer:

MFA optional
for HR administrators

Gap:

Shared authentication control incomplete.

63. Gap Scenario 4 — Provider Assurance

Provider physical controls are marked:

Inherited

but:

Latest provider assurance report
is 18 months old.

Gap:

Inherited control assurance is stale.

64. Gap Scenario 5 — Data Residency

Provider:

Offers EU region

Customer:

Analytics workload deployed in US

Gap:

Customer has failed to apply the approved-region responsibility.

Part 12 — Perform Root Cause Analysis

Step 65 — Logging Gap

Ask:

Why were accounts missing?

Possible chain:

Logging not enabled
      ↓
Account created manually
      ↓
Baseline not automatically deployed
      ↓
No centralized account-vending process

Root cause:

Cloud account creation does not automatically enforce the enterprise logging baseline.

66. Backup Gap

Root cause:

Backup capability misunderstood
as recovery assurance.

Corrective action:

Establish quarterly recovery testing for critical cloud workloads.

67. SaaS MFA Gap

Root cause:

SaaS onboarding checklist
did not include administrator MFA.

Corrective action:

Add mandatory privileged MFA validation to SaaS onboarding and quarterly review.

Part 13 — Define Remediation

Step 68 — Create Actions

For each gap define:

Correction

Root Cause

Corrective Action

Owner

Target

Evidence

69. Example Logging Remediation

Correction:

Connect 3 missing accounts to SIEM.

Corrective action:

Modify account provisioning workflow
to automatically deploy logging.

70. Example Provider Assurance Remediation

Correction:

Obtain current assurance report.

Corrective action:

Implement annual provider evidence
renewal monitoring.

Part 14 — Validate Internal Ownership

Step 71 — Assign One Internal Owner

Even for shared controls, CloudNova should have an internal owner.

Example:

Cloud Logging
→ SOC Manager

Do not assign:

Provider + Customer

as the internal owner.

The customer organization still needs accountability.

72. Owner vs Operator

Example:

Control Owner:
IAM Director

Operator:
Cloud Platform Team

The owner remains accountable even if another team performs the control.

73. Evidence Owner

Example:

Control:
Privileged Access Review

Control Owner:
IAM Director

Evidence Owner:
IAM Operations

This improves audit readiness.

Part 15 — Validate Responsibility by Service Model

Step 74 — Compare IaaS

Ask:

What does customer manage?

Expected:

More technical responsibility

75. Compare PaaS

Expected:

Provider manages OS/platform
Customer manages configuration/data/application

76. Compare SaaS

Expected:

Provider manages most technology
Customer still manages users/data/configuration

77. Responsibility Trend

On-Premises
      ↓
IaaS
      ↓
PaaS
      ↓
SaaS

Customer Technical Responsibility
Decreases

But:

Customer Accountability
Does Not Disappear

Part 16 — Build an ISO/IEC 27017 Mapping

Step 78 — Map Responsibility Concepts

For each enterprise control, identify whether ISO/IEC 27017 cloud guidance is relevant.

Examples:

Cloud Responsibility Mapping

Administrative Operations

Cloud Monitoring

Virtual Environment Separation

Cloud Asset Return

Network Security

79. Example Mapping

Enterprise Control:
CLOUD-GOV-001

Control:
Cloud Responsibility Matrix

ISO/IEC 27017:
Cloud roles and responsibilities

Part 17 — Build an ISO/IEC 27018 Privacy Mapping

Step 80 — Select PII Services

Examples:

HR SaaS

CRM

Support Platform

For each identify privacy responsibilities involving:

Access

Location

Subprocessors

Retention

Deletion

Incident Response

81. Example Privacy Responsibility

HR SaaS:

Provider:

Operates platform
Processes employee data

Customer:

Defines purpose

Configures users

Defines retention

Handles employee rights

Shared:

Incident response

Deletion

Part 18 — Audit Simulation

Step 82 — Auditor Selects AWS EC2

Auditor asks:

Who is responsible for operating-system patching?

Answer:

CloudNova

Evidence:

Patch Compliance Report

83. Auditor Selects Physical Security

Question:

How do you know the provider protects its data centers?

Answer should include:

Inherited Control

Provider Assurance

Current Report

Scope Review

84. Auditor Selects Logging

Question:

Who is responsible for cloud administrative logging?

Answer:

Shared

Then explain:

Provider:
Generates log capability

Customer:
Enables, centralizes, retains, monitors

85. Auditor Selects HR SaaS

Question:

Who removes terminated employee accounts?

Answer:

CloudNova HR / IAM

This remains a customer responsibility.

Part 19 — Build Executive Responsibility Summary

Step 86 — Create

11-Executive-Responsibility-Summary.md

Include:

Cloud Services Reviewed

Provider Responsibilities

Customer Responsibilities

Shared Controls

Inherited Controls

High-Risk Responsibility Gaps

Remediation Priorities

87. Example Executive Dashboard

Metric	Result
Cloud Services Reviewed	12
Shared Controls	18
Customer Controls	27
Inherited Controls	14
Responsibility Gaps	6
High-Risk Gaps	2
Stale Provider Evidence	1

88. Example Executive Narrative

CloudNova has documented provider, customer, shared, and inherited control responsibilities across its IaaS, PaaS, and SaaS environments. Most responsibility boundaries are clearly defined, but material gaps remain in centralized cloud logging, SaaS privileged MFA, recovery testing, and provider assurance freshness. Each gap has been assigned an internal control owner and corrective action.

Part 20 — Responsibility Matrix Quality Review

Verify each row answers:

What is the control?

What does the provider do?

What does the customer do?

Is it shared or inherited?

Who owns the customer side?

What evidence proves provider activity?

What evidence proves customer activity?

Is there a gap?

If any answer is unclear, improve the matrix.

89. Final Lab Deliverables

Your completed lab should contain:

Cloud-Compliance-Lab01/
│
├── 01-Cloud-Service-Inventory.md
├── 02-IaaS-Responsibility-Matrix.md
├── 03-PaaS-Responsibility-Matrix.md
├── 04-SaaS-Responsibility-Matrix.md
├── 05-Enterprise-Control-Responsibility-Register.md
├── 06-Provider-Responsibility-Map.md
├── 07-Customer-Control-Register.md
├── 08-Shared-Control-Register.md
├── 09-Inherited-Control-Evidence-Map.md
├── 10-Responsibility-Gap-Register.md
└── 11-Executive-Responsibility-Summary.md

90. Lab Validation Checklist

Before completing the mission:

Inventory

• Cloud services inventoried.

• Providers identified.

• Service models classified.

• Business owners identified.

• Technical owners identified.

• Data classifications identified.

• Criticality assigned.

IaaS

• Physical responsibility mapped.

• Hypervisor mapped.

• Guest OS mapped.

• IAM mapped.

• Network mapped.

• Application mapped.

• Data mapped.

• Logging mapped.

• Backup mapped.

• Incident response mapped.

PaaS

• Platform responsibility mapped.

• Customer configuration mapped.

• Database/application responsibility mapped.

• IAM mapped.

• Encryption mapped.

• Logging mapped.

• Backup mapped.

SaaS

• Provider application responsibility mapped.

• User responsibility mapped.

• MFA mapped.

• Sharing mapped.

• Retention mapped.

• Logging mapped.

• Deletion mapped.

• Incident response mapped.

Ownership

• Customer control owners assigned.

• Control operators identified.

• Evidence owners identified.

• Shared controls have internal owners.

Provider Assurance

• Inherited controls identified.

• Provider evidence mapped.

• Assurance scope reviewed.

• Evidence freshness considered.

Gaps

• Responsibility gaps identified.

• Risk documented.

• Root cause identified.

• Corrective actions assigned.

• Target dates established.

• Retest evidence defined.

91. Skills You Practiced

By completing this lab, you have practiced:

Cloud Service Inventory

IaaS Responsibility Analysis

PaaS Responsibility Analysis

SaaS Responsibility Analysis

Provider Responsibility Mapping

Customer Control Ownership

Shared Control Governance

Inherited Control Assurance

Provider Evidence Review

Cloud Risk Assessment

Gap Identification

Corrective Action Planning

Cloud Audit Readiness

These skills are directly relevant to roles such as:

• GRC Analyst.

• Cloud Compliance Analyst.

• Cloud Security Analyst.

• Third-Party Risk Analyst.

• ISO Cloud Security Consultant.

• Security Assurance Analyst.

• Cloud Governance Analyst.

92. Portfolio Challenge

Package your work as:

CloudNova Technologies
Cloud Compliance Shared Responsibility Assessment

Include:

Executive Summary

Cloud Service Inventory

IaaS Matrix

PaaS Matrix

SaaS Matrix

Provider Responsibility Map

Customer Control Register

Shared Control Register

Inherited Control Evidence Map

Gap Register

Remediation Plan

Do not use confidential information from a real employer or customer in a public portfolio.

Mission Complete

You have now transformed the shared-responsibility concept from:

Provider vs Customer

into a practical enterprise governance model:

Cloud Service
      ↓
Control
      ↓
Provider Responsibility
      +
Customer Responsibility
      ↓
Internal Owner
      ↓
Provider Evidence
      +
Customer Evidence
      ↓
Gap Assessment
      ↓
Remediation

This is how shared responsibility becomes auditable cloud governance.

What’s Next?

➡️ Next: Lab 02 — Perform a Cloud Compliance Assessment

In the next lab, you will use the responsibility model you created here to assess a fictional multi-cloud environment against cloud security and compliance requirements.

You will perform the workflow:

Define Assessment Scope
        ↓
Validate Cloud Inventory
        ↓
Review Provider Assurance
        ↓
Test Shared Responsibilities
        ↓
Assess IAM
        ↓
Assess Logging
        ↓
Assess Encryption
        ↓
Assess Configuration
        ↓
Assess Data Residency
        ↓
Assess Backup & Recovery
        ↓
Document Findings
        ↓
Perform Root Cause Analysis
        ↓
Build Remediation Plan

You will create a Cloud Compliance Assessment Plan, Control Testing Worksheet, Evidence Request List, Configuration Assessment, Cloud Findings Register, Risk Impact Analysis, and Remediation Tracker.