Runbook 01 — Cloud Compliance Assessment & Evidence Collection

Runbook Information

Item	Details
Runbook	01 — Cloud Compliance Assessment & Evidence Collection
Module	Cloud Compliance & ISO Cloud Standards
Difficulty	Advanced
Primary Role	Cloud GRC Analyst / Cloud Compliance Analyst
Supporting Roles	Cloud Security, IAM, SOC, Platform Engineering, Privacy, Legal, Procurement, Internal Audit
Applicable Environments	IaaS, PaaS, SaaS, Multi-Cloud
Primary Standards	ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018
Primary Output	Cloud Compliance Assessment & Evidence Package
Runbook Type	Cloud Assurance / Control Testing

Purpose

This runbook provides a reusable procedure for performing periodic or event-driven cloud compliance assessments.

The process covers:

Assessment Trigger
      ↓
Scope Definition
      ↓
Cloud Inventory Validation
      ↓
Shared Responsibility Review
      ↓
Provider Assurance Review
      ↓
Evidence Collection
      ↓
Evidence Validation
      ↓
Control Testing
      ↓
Finding Identification
      ↓
Risk Impact
      ↓
Root Cause Analysis
      ↓
Remediation
      ↓
Retesting
      ↓
Management Reporting

The objective is to determine whether cloud controls are:

• Appropriately designed.

• Implemented.

• Operating consistently.

• Supported by reliable evidence.

• Aligned with provider/customer responsibility.

• Connected to enterprise risk.

• Ready for internal or external assurance.

Runbook Success Outcome

At the end of the process, the assessment team should be able to answer:

What cloud environments are in scope?

Who owns them?

Which data do they process?

Which controls apply?

Who operates each control?

Which controls are inherited?

What provider evidence supports them?

What customer evidence exists?

Which controls failed?

What risk do those failures create?

Who will remediate them?

Were corrective actions independently validated?

Assessment Triggers

Run this procedure when any of the following occurs:

Scheduled Cloud Compliance Review

ISO Internal Audit

Certification Readiness Review

Major Cloud Migration

New Critical Cloud Provider

Major Cloud Architecture Change

Security Incident

Regulatory / Contractual Change

Material Provider Change

High-Risk Cloud Finding

Phase 1 — Initiate the Assessment

Step 1 — Record the Assessment Trigger

Create an assessment record.

Include:

Assessment ID

Trigger

Requestor

Date

Lead Assessor

Target Completion

Example:

Assessment ID:
CCA-2026-03

Trigger:
Annual Cloud Compliance Review

Step 2 — Define the Objective

Example:

Determine whether in-scope cloud governance, security, privacy, and compliance controls are appropriately implemented and operating across production cloud environments.

Step 3 — Identify Stakeholders

Typical participants include:

GRC

Cloud Engineering

Cloud Security

IAM

SOC

Data Owners

Privacy

Legal

Procurement

Internal Audit

Step 4 — Assign Assessment Lead

The lead coordinates:

• Scope.

• Evidence requests.

• Testing.

• Findings.

• Reporting.

• Remediation tracking.

Phase 2 — Define Assessment Scope

Step 5 — Identify In-Scope Providers

Document:

AWS

Azure

Google Cloud

Critical SaaS Providers

Private Cloud

where applicable.

Step 6 — Identify In-Scope Cloud Objects

Include:

AWS Accounts

Azure Subscriptions

GCP Projects

SaaS Tenants

Cloud Regions

Production Workloads

Step 7 — Identify In-Scope Services

Examples:

Compute

Object Storage

Managed Database

Identity

Logging

Kubernetes

Serverless

SaaS Applications

Step 8 — Identify In-Scope Data

Document relevant classifications:

Public

Internal

Confidential

Restricted

PII

Payment Data

Step 9 — Define Assessment Period

Example:

01 January 2026
through
30 June 2026

Point-in-time evidence may not be sufficient for controls expected to operate throughout the period.

Step 10 — Define Criteria

Possible criteria include:

ISO/IEC 27001

ISO/IEC 27017

ISO/IEC 27018

Cloud Security Policy

Cloud Configuration Standard

IAM Standard

Logging Standard

Data Residency Requirements

Backup & Recovery Standard

Provider Contracts

Phase 3 — Validate Cloud Inventory

Step 11 — Obtain Approved Inventory

Request:

Cloud Account Inventory

SaaS Inventory

Provider Inventory

Application Inventory

Data Inventory

Step 12 — Compare Against Discovery Sources

Useful sources include:

Cloud Organizations

SSO Applications

Procurement

Expense Records

CSPM

CASB

DNS / Network Discovery

Step 13 — Identify Inventory Differences

Use:

Known
Unknown
Duplicate
Inactive
Unowned

Step 14 — Validate Ownership

For every environment confirm:

Business Owner

Technical Owner

Security Owner

Step 15 — Validate Criticality

Confirm classifications such as:

Critical

High

Moderate

Low

Step 16 — Validate Data Classification

Check whether system metadata aligns with actual data.

Step 17 — Record Inventory Gaps

Example:

One active SaaS service processing customer information is absent from the approved Cloud Service Inventory.

Create a finding candidate if material.

Phase 4 — Review Shared Responsibility

Step 18 — Obtain Responsibility Matrices

Request provider/customer responsibility documentation for critical services.

Step 19 — Classify Responsibility

Use:

Provider

Customer

Shared

Inherited

Step 20 — Validate Service-Specific Responsibility

Do not assume responsibility is the same for every service from the same provider.

Example:

Virtual Machine
≠
Managed Database
≠
SaaS

Step 21 — Identify Provider Activity

Example:

Control:
Logging

Provider:
Generates audit-event capability

Step 22 — Identify Customer Activity

Example:

Customer:
Enables logging
Centralizes logs
Defines retention
Monitors events

Step 23 — Validate Internal Ownership

Every customer and shared responsibility should have an internal owner.

Avoid:

Owner:
Cloud Provider + Customer

Instead:

Internal Owner:
SOC Manager

Step 24 — Identify Responsibility Gaps

Example:

Provider provides backup capability

Customer assumes backup includes recovery testing

No recovery test exists

Document the gap.

Phase 5 — Review Provider Assurance

Step 25 — Identify Critical Providers

Use provider tiering or service criticality.

Step 26 — Request Provider Evidence

Examples:

ISO Certificates

SOC Reports

ISO/IEC 27017 Assurance

ISO/IEC 27018 Assurance

Security Documentation

Resilience Information

Step 27 — Validate Evidence Currency

Use:

Current

Approaching Expiry

Stale

Unavailable

Step 28 — Validate Scope

Verify:

Provider Entity

Service

Region

Period

Control Scope

Step 29 — Review Exceptions

Inspect:

Audit Exceptions

Qualified Conclusions

Control Failures

Subservice Organizations

Step 30 — Evaluate Customer Impact

For each provider exception ask:

Does it affect our service?

Which inherited control?

Which risk?

Do we need treatment?

Step 31 — Review Customer Responsibilities

Provider reports may state requirements such as:

Enable Logging

Manage Users

Review Access

Protect Credentials

Configure Backups

Map these to customer controls.

Phase 6 — Build the Evidence Request

Step 32 — Create Evidence Request Tracker

Use:

Request	Evidence	Owner	Due	Status

Step 33 — Request Governance Evidence

Examples:

Cloud Inventory

Responsibility Matrix

Cloud Control Framework

Approved Region Register

Exception Register

Step 34 — Request IAM Evidence

Examples:

Privileged User Inventory

MFA Coverage

Access Review Records

Service Account Inventory

Break-Glass Accounts

Step 35 — Request Configuration Evidence

Examples:

CSPM Reports

Cloud Policy Reports

Resource Inventory

Public Exposure Report

Security Baseline Report

Step 36 — Request Logging Evidence

Examples:

Log Source Inventory

SIEM Coverage

Retention Configuration

Detection Rules

Logging Exceptions

Step 37 — Request Data Protection Evidence

Examples:

Encryption Coverage

Key Permissions

Key Rotation

Data Classification

Region Configuration

Step 38 — Request Resilience Evidence

Examples:

Backup Status

Recovery Tests

DR Tests

Backup Exceptions

Step 39 — Request SaaS Evidence

Examples:

Admin Users

MFA Status

External Users

Audit Logs

Integrations

Retention

Provider Assurance

Phase 7 — Validate Evidence Quality

Step 40 — Verify Evidence Relevance

Ask:

Does this evidence prove the control?

Step 41 — Verify Scope

Check:

Correct accounts?

Correct systems?

Correct user population?

Step 42 — Verify Period

Ask:

Does it cover the assessment period?

Step 43 — Verify Completeness

Example:

Production Accounts:
50

Evidence:
48

Result:
Incomplete

Step 44 — Verify Reliability

Prefer evidence from authoritative systems.

Examples:

Cloud API

IAM Platform

SIEM

CSPM

GRC Workflow

Step 45 — Avoid Excessive Screenshot Reliance

A screenshot may support one sample.

It does not normally prove a large population.

Step 46 — Record Evidence Metadata

Include:

Evidence ID

Source

Date

Scope

Owner

Control

Phase 8 — Plan Control Testing

Step 47 — Build the Control Testing Worksheet

Use:

Control	Requirement	Responsibility	Population	Test	Result

Step 48 — Identify Population

Examples:

64 Privileged Users

150 Storage Resources

20 Critical Workloads

15 Production Accounts

Step 49 — Validate Population Completeness

Ask:

How was the population generated?

Does it cover all in-scope systems?

Can anything bypass it?

Step 50 — Select Testing Method

Use:

Complete Population

Risk-Based Sampling

Random Sampling

Judgmental Sampling

Cloud APIs often make full-population testing practical.

Phase 9 — Test IAM Controls

Step 51 — Test Privileged MFA

Procedure:

Identify privileged users
      ↓
Validate MFA
      ↓
Identify failures
      ↓
Review exceptions

Pass condition:

100% privileged identities
meet approved authentication requirement

Step 52 — Test Federation

Identify local accounts bypassing enterprise identity.

Step 53 — Test Privileged Role Assignments

Ask:

Approved?

Business need?

Least privilege?

Temporary where required?

Step 54 — Test Access Reviews

Review:

Population

Reviewer

Frequency

Decisions

Removal Actions

Step 55 — Test Break-Glass Accounts

Verify:

Restricted Use

Secure Credentials

Monitoring

Periodic Testing

Step 56 — Test Workload Identities

Review:

Service Accounts

Managed Identities

Static Keys

Credential Age

Privilege

Phase 10 — Test Logging & Monitoring

Step 57 — Define Required Log Sources

Examples:

Administrative Logs

Authentication Logs

Network Logs

Data Access Logs

Step 58 — Measure Logging Coverage

Example:

Production Accounts:
50

Integrated:
48

Record uncovered environments.

Step 59 — Validate Retention

Compare actual retention with standard.

Step 60 — Validate Log Protection

Ask:

Who can delete logs?

Who can change retention?

Are changes logged?

Step 61 — Test Detection

Sample events:

New Administrator

Logging Disabled

Public Storage

Suspicious Login

Trace:

Event
→ Alert
→ Investigation
→ Closure

Phase 11 — Test Cloud Configuration

Step 62 — Assess Public Exposure

Evaluate:

Storage

Databases

Administrative Interfaces

Security Groups

SaaS Sharing

Step 63 — Review Approved Exceptions

A public resource may be legitimate.

Confirm:

Business Need

Approval

Risk

Controls

Step 64 — Test Administrative Ports

Look for:

SSH

RDP

Database Management

Administrative APIs

open to unrestricted sources.

Step 65 — Test Compute Baseline

Review:

Approved Image

Patching

EDR

Host Firewall

Logging

Step 66 — Test Configuration Drift

Determine whether the organization detects changes from approved baseline.

Step 67 — Review Policy-as-Code

Assess:

Coverage

Rules

Enforcement

Exceptions

Change Management

Phase 12 — Test Encryption & Key Management

Step 68 — Identify Protected Population

Examples:

Databases

Object Storage

Disks

Backups

Step 69 — Validate Encryption

Compare against classification-based requirements.

Step 70 — Review Key Model

Identify:

Provider-Managed

Customer-Managed

Externally Managed

Step 71 — Test Key Access

Check:

Administrators

Applications

Key Usage

Logging

Access Review

Step 72 — Identify Excessive Key Permissions

Broad key access can undermine encryption controls.

Phase 13 — Test Data Residency

Step 73 — Identify Restricted Datasets

Use:

Data Inventory

Classification Register

Step 74 — Verify Primary Region

Compare:

Actual Region
vs
Approved Region

Step 75 — Verify Backups

Check backup and DR locations.

Step 76 — Review Processing Locations

Include:

Analytics

AI Services

Support Platforms

Integrations

Step 77 — Review Cross-Border Transfers

Check:

Approval

Purpose

Current Need

Security Controls

Step 78 — Review Subprocessors

Validate relevant provider/subprocessor locations.

Step 79 — Review Support Access

Determine whether support-access locations are relevant to applicable requirements.

Phase 14 — Test Backup & Recovery

Step 80 — Validate Backup Coverage

For every critical workload verify:

Backup Enabled

Frequency

Retention

Encryption

Step 81 — Review Backup Failures

Check whether failed jobs are detected and remediated.

Step 82 — Test Recovery Evidence

Remember:

Backup Success
≠
Recoverability

Review actual restore tests.

Step 83 — Compare Against Required Frequency

Example:

Required:
Quarterly

Actual:
No test in 12 months

Potential finding.

Step 84 — Review Recovery Objectives

Compare actual results against:

RTO

RPO

where defined.

Phase 15 — Assess SaaS

Step 85 — Identify Critical SaaS

Include systems processing:

PII

Customer Data

Source Code

Identity

Financial Data

Step 86 — Test SaaS Administrators

Validate:

Admin List

MFA

Ownership

Access Review

Step 87 — Test Guest Users

Review inactive or unnecessary external accounts.

Step 88 — Test Sharing Controls

Check:

Anonymous Links

External Sharing

Public Objects

Step 89 — Test SaaS Integrations

Inventory:

OAuth Applications

API Tokens

Connected Apps

Confirm ownership and need.

Step 90 — Test SaaS Logging

Determine whether audit logs are:

Available

Enabled

Exported

Retained

Reviewed

Step 91 — Review SaaS Provider Assurance

Apply the same provider-assurance procedure.

Phase 16 — Identify Findings

Step 92 — Establish Finding Criteria

Every finding should include:

Requirement

Condition

Evidence

Risk

Step 93 — Write Specific Findings

Avoid:

Cloud security is weak.

Prefer:

Three production cloud accounts were not forwarding required administrative audit logs to the enterprise SIEM during the assessment period.

Step 94 — Assign Severity

Use approved methodology.

Possible levels:

Critical

High

Medium

Low

Step 95 — Validate Findings With Owners

Confirm factual accuracy.

Do not allow valid issues to disappear through wording negotiation.

Phase 17 — Assess Risk Impact

Step 96 — Link Finding to Risk

Example:

MFA Failure
      ↓
Privileged Account Compromise

Step 97 — Determine Existing Risk Record

If a matching risk exists:

Update it

If not:

Create / Escalate

according to risk methodology.

Step 98 — Review Residual Risk

Control failure may increase residual risk.

Step 99 — Identify Compliance Impact

Map affected:

ISO Controls

ISO 27017 Guidance

ISO 27018 Controls

Customer Contracts

Internal Standards

Phase 18 — Perform Root Cause Analysis

Step 100 — Separate Correction From Root Cause

Example:

Issue:
Logging missing

Correction:

Enable logging

Root cause may be:

Account provisioning
does not deploy logging baseline

Step 101 — Use Five Whys Where Helpful

Ask:

Why did it happen?

Why was it not prevented?

Why was it not detected?

Step 102 — Avoid Weak Root Causes

Avoid:

Human error

Forgot

Mistake

unless backed by deeper process analysis.

Phase 19 — Define Remediation

Step 103 — Define Correction

Fix immediate condition.

Step 104 — Define Corrective Action

Address systemic cause.

Step 105 — Assign Owner

Use a person/role with authority to remediate.

Step 106 — Define Target Date

Base on:

Severity

Risk

Dependencies

Implementation Effort

Step 107 — Define Closure Evidence

Examples:

Configuration Export

Updated Workflow

Policy-as-Code Rule

Completed Recovery Test

Current Provider Report

Phase 20 — Track Remediation

Step 108 — Maintain Remediation Tracker

Use:

Finding	Action	Owner	Target	Status

Step 109 — Use Standard Status

Open

Planned

In Progress

Blocked

Ready for Retest

Closed

Step 110 — Escalate Overdue Findings

Escalation should be risk based.

Example:

High Finding
      ↓
CISO / Risk Owner

Phase 21 — Retest Findings

Step 111 — Do Not Close on Attestation

Avoid:

Owner says fixed
      ↓
Closed

Step 112 — Reperform Original Test

Use same or improved test procedure.

Step 113 — Validate Full Population Where Appropriate

Example:

Original:
3 / 50 accounts missing logs

Retest:
50 / 50 integrated

Step 114 — Validate Root Cause Remediation

Also test:

New account provisioning
automatically enables logging

Step 115 — Determine Retest Result

Use:

Effective

Partially Effective

Ineffective

Step 116 — Close or Reopen

Pass
→ Close

Fail
→ Reopen

Phase 22 — Update Governance Artifacts

Step 117 — Update Cloud Inventory

Add missing services and owners.

Step 118 — Update Responsibility Matrix

Clarify unclear responsibility.

Step 119 — Update Control Library

Where control design changes.

Step 120 — Update SoA

If applicable control status changed.

Step 121 — Update Risk Register

Reflect changed residual risk.

Step 122 — Update Risk Treatment Plan

Add remediation where needed.

Step 123 — Update Exception Register

Capture accepted deviations.

Phase 23 — Build Management Reporting

Step 124 — Prepare Executive Summary

Include:

Assessment Scope

Overall Control Status

High Findings

Top Cloud Risks

Provider Issues

Remediation Priorities

Step 125 — Prepare Metrics

Useful examples:

Cloud Inventory Coverage

Privileged MFA Coverage

Logging Coverage

Encryption Coverage

Approved Region Coverage

Recovery Test Coverage

Current Provider Assurance

Step 126 — Highlight Trends

Example:

Logging Coverage:
Q1 88%
Q2 94%
Q3 100%

Trends are often more useful than one-time percentages.

Step 127 — Highlight Systemic Weaknesses

Examples:

Manual Account Provisioning

Fragmented IAM

Weak SaaS Governance

Incomplete Provider Assurance

Manual Recovery Scheduling

Phase 24 — Continuous Evidence Collection

Step 128 — Identify Automatable Evidence

Examples:

MFA

Logging

Encryption

Region

Public Exposure

Backup Status

Step 129 — Define Evidence Frequency

Example:

Public Exposure
→ Continuous

MFA
→ Daily

Provider Assurance
→ Annual

Step 130 — Define Evidence Freshness

Document stale thresholds.

Step 131 — Integrate Cloud APIs

Where possible use:

Cloud API
      ↓
Evidence Collector
      ↓
Evidence Repository

Step 132 — Monitor Evidence Pipelines

Track:

Collection Failures

Missing Accounts

Stale Evidence

API Errors

Phase 25 — Evidence Packaging for Audit

Step 133 — Build Evidence Index

Use:

Evidence ID	Control	Source	Period	Owner

Step 134 — Remove Unnecessary Sensitive Data

Do not provide:

Passwords

Private Keys

Sensitive Customer Records

unless strictly required and appropriately controlled.

Step 135 — Organize Evidence by Control

Example:

IAM-002/
├── MFA-Coverage
├── Exception-Register
└── Retest

Step 136 — Maintain Traceability

Auditor should be able to follow:

Requirement
      ↓
Control
      ↓
Evidence
      ↓
Test
      ↓
Finding
      ↓
Remediation

Cloud Compliance Assessment Checklist

Initiation

• Assessment trigger documented.

• Objective defined.

• Lead assigned.

• Stakeholders identified.

Scope

• Providers identified.

• Accounts/subscriptions/projects identified.

• SaaS included.

• Data scoped.

• Regions scoped.

• Assessment period defined.

• Criteria defined.

Inventory

• Inventory obtained.

• Discovery comparison performed.

• Unknown services identified.

• Owners validated.

• Data classifications reviewed.

Responsibility

• Responsibility matrices reviewed.

• Provider controls identified.

• Customer controls identified.

• Shared controls identified.

• Inherited controls identified.

• Internal owners validated.

Provider Assurance

• Critical providers identified.

• Current assurance collected.

• Scope validated.

• Exceptions reviewed.

• Customer responsibilities mapped.

Evidence

• Evidence request list issued.

• Evidence sources validated.

• Period validated.

• Scope validated.

• Completeness validated.

• Evidence metadata recorded.

IAM

• Privileged population validated.

• MFA tested.

• Federation tested.

• Access reviews tested.

• Break-glass accounts tested.

• Workload identities tested.

Logging

• Required sources identified.

• Coverage tested.

• Retention validated.

• Protection reviewed.

• Detection tested.

Configuration

• Public exposure tested.

• Administrative ports tested.

• Secure baseline tested.

• Drift monitoring assessed.

• Policy-as-code reviewed.

Data Protection

• Encryption tested.

• Key model reviewed.

• Key access reviewed.

Residency

• Restricted datasets identified.

• Primary locations validated.

• Backup locations validated.

• Transfers assessed.

• Subprocessors considered.

• Support access considered.

Recovery

• Backup coverage tested.

• Backup failures reviewed.

• Recovery testing validated.

• RTO/RPO considered.

SaaS

• SaaS admins tested.

• MFA tested.

• Guest users reviewed.

• Sharing reviewed.

• Integrations reviewed.

• SaaS logging reviewed.

• Provider assurance reviewed.

Findings

• Requirement identified.

• Condition documented.

• Evidence recorded.

• Risk defined.

• Severity assigned.

• Owner assigned.

Remediation

• Correction defined.

• Root cause identified.

• Corrective action defined.

• Target assigned.

• Closure evidence defined.

• Retest planned.

Closure

• Retesting completed.

• Findings closed or reopened.

• Risk updated.

• SoA updated where required.

• Control library updated.

• Management report issued.

Recommended Assessment Repository

Cloud-Compliance-Assessment/
│
├── 01-Scope/
│   ├── Assessment-Plan
│   └── Stakeholders
│
├── 02-Inventory/
│   ├── Cloud-Inventory
│   └── SaaS-Inventory
│
├── 03-Responsibility/
│   └── Shared-Responsibility-Matrix
│
├── 04-Provider-Assurance/
│   ├── Certifications
│   ├── SOC-Reports
│   └── Provider-Reviews
│
├── 05-Evidence/
│   ├── IAM
│   ├── Logging
│   ├── Configuration
│   ├── Encryption
│   ├── Residency
│   └── Recovery
│
├── 06-Testing/
│   └── Control-Testing-Worksheets
│
├── 07-Findings/
│   └── Findings-Register
│
├── 08-Remediation/
│   └── Remediation-Tracker
│
├── 09-Retest/
│   └── Retest-Evidence
│
└── 10-Reporting/
    └── Executive-Summary

Quick Reference — Assessment Decision Tree

Cloud Environment In Scope?
      │
      ├── No → Document Exclusion
      │
      └── Yes
             ↓
Inventory Complete?
      │
      ├── No → Raise Governance Gap
      │
      └── Yes
             ↓
Responsibility Defined?
      │
      ├── No → Clarify Provider/Customer Responsibility
      │
      └── Yes
             ↓
Evidence Available?
      │
      ├── No → Evidence Gap
      │
      └── Yes
             ↓
Evidence Complete & Current?
      │
      ├── No → Assurance Gap
      │
      └── Yes
             ↓
Control Operating?
      │
      ├── No → Finding
      │
      └── Yes
             ↓
Effective?
      │
      ├── No → Control Design Gap
      │
      └── Yes → Pass

Quick Reference — Evidence Validation

For every evidence item ask:

Right Source?

Right Scope?

Right Period?

Complete Population?

Reliable?

Reproducible?

Current?

Protected?

Quick Reference — Finding Structure

Use:

[Requirement] requires [expected condition]. The assessment identified [actual condition] based on [evidence]. This may result in [risk/impact].

Example:

The Cloud Logging Standard requires centralized administrative logging for all production cloud accounts. The assessment identified two of fifteen production environments that were not fully forwarding administrative logs to the enterprise SIEM. This reduces CloudNova’s ability to detect and investigate unauthorized administrative activity.

Common Runbook Failures

Failure 1 — Starting With Evidence Requests Before Scope

Teams collect unnecessary information.

Failure 2 — Assuming Inventory Is Complete

Unknown cloud services escape assessment.

Failure 3 — Ignoring Shared Responsibility

The wrong party is asked for evidence.

Failure 4 — Provider Certificate Accepted Without Scope Review

Inherited controls may not actually be covered.

Failure 5 — Current Screenshot Used for Historical Control

Operation throughout the assessment period is not demonstrated.

Failure 6 — Only IaaS Is Assessed

SaaS risk remains unmanaged.

Failure 7 — Configuration Scanning Replaces Control Testing

Governance and operating effectiveness are missed.

Failure 8 — Findings Have No Requirement

They become opinions rather than audit observations.

Failure 9 — Immediate Fix Equals Closure

Root cause remains.

Failure 10 — Assessment Does Not Update Risk

Compliance and enterprise risk remain disconnected.

Practical Cloud Assurance Mindset

A weak assessment asks:

Is the checkbox green?

A stronger assessment asks:

Does the configuration meet the requirement?

A mature assessment asks:

Is the control well designed, operating across the complete population, supported by reliable evidence, aligned with shared responsibility, reducing the intended risk, and able to remain effective as the cloud environment changes?

That is the mindset required for meaningful cloud compliance assurance.

Runbook Deliverables

A completed assessment package should contain:

01 — Assessment Plan

02 — Validated Cloud Inventory

03 — Responsibility Matrix

04 — Provider Assurance Review

05 — Evidence Request Register

06 — Evidence Index

07 — IAM Assessment

08 — Logging Assessment

09 — Configuration Assessment

10 — Encryption Assessment

11 — Data Residency Assessment

12 — Backup & Recovery Assessment

13 — SaaS Assessment

14 — Control Testing Worksheets

15 — Findings Register

16 — Risk Impact Analysis

17 — Root Cause Records

18 — Remediation Tracker

19 — Retest Records

20 — Executive Summary

Runbook Completion Criteria

The assessment is complete when:

Scope is documented

Cloud inventory is validated

Responsibilities are understood

Provider assurance is current

Evidence is complete

Critical controls are tested

Findings are documented

Risk impact is assessed

Root causes are identified

Corrective actions are assigned

Retesting is completed or scheduled

Management receives the assessment result

Runbook Complete

You now have a repeatable enterprise workflow for moving from:

Cloud Environment

to:

Validated Inventory
      ↓
Responsibility Mapping
      ↓
Evidence
      ↓
Control Testing
      ↓
Findings
      ↓
Risk
      ↓
Remediation
      ↓
Retesting
      ↓
Management Assurance

This procedure can be reused for scheduled assessments, internal audits, ISO certification readiness, major cloud changes, provider reviews, and event-driven cloud compliance investigations.

What’s Next?

➡️ Next: Runbook 02 — Cloud Compliance Exception, Remediation & Continuous Monitoring

In the next and final runbook for this module, you will operationalize what happens after a cloud control fails or an exception is requested.

You will build the lifecycle:

Control Violation
      ↓
Determine Immediate Risk
      ↓
Correct Immediate Exposure
      ↓
Exception or Remediation?
      ↓
Risk Assessment
      ↓
Compensating Controls
      ↓
Approval
      ↓
Corrective Action
      ↓
Continuous Monitoring
      ↓
Retest
      ↓
Close / Renew / Escalate

The runbook will connect cloud exceptions, risk acceptance, remediation, policy-as-code, continuous control monitoring, evidence freshness, and management escalation into one repeatable operating process.