04 ISO 27018 Privacy Controls

ISO/IEC 27018 provides guidance for protecting Personally Identifiable Information (PII) processed within public cloud environments.

It is especially relevant when a cloud service provider processes personal information on behalf of its customers.

The standard helps cloud customers and cloud providers address privacy questions such as:

What personal data is processed?
        ↓
Why is it processed?
        ↓
Where is it stored?
        ↓
Who can access it?
        ↓
Which subprocessors are involved?
        ↓
How long is it retained?
        ↓
How is it deleted?
        ↓
How are disclosures controlled?
        ↓
How are privacy incidents handled?

ISO/IEC 27018 does not replace ISO/IEC 27001.

Instead, it strengthens the privacy and PII protection aspects of cloud governance.

A useful relationship is:

ISO/IEC 27001
      ↓
ISMS Foundation

ISO/IEC 27017
      ↓
Cloud Security Guidance

ISO/IEC 27018
      ↓
Public Cloud PII Protection

For GRC professionals, ISO/IEC 27018 is particularly useful because cloud privacy requires strong coordination across:

Security.
Privacy.
Legal.
Procurement.
Cloud engineering.
Vendor management.
Data owners.
Cloud providers.

Learning Objectives

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

Explain the purpose of ISO/IEC 27018.
Understand how it relates to ISO/IEC 27001 and ISO/IEC 27017.
Understand cloud privacy roles.
Identify PII processed in cloud environments.
Build a Cloud PII Inventory.
Understand purpose limitation.
Understand processing instructions.
Evaluate cloud-provider privacy transparency.
Assess data location.
Assess data residency.
Assess cross-border transfers.
Govern subprocessors.
Understand PII disclosure controls.
Establish retention requirements.
Establish secure deletion requirements.
Understand access and correction support.
Understand privacy incident responsibilities.
Map privacy controls to cloud risks.
Build ISO/IEC 27018 evidence requirements.
Support cloud privacy audits and assessments.

1. What Is ISO/IEC 27018?

ISO/IEC 27018 provides privacy-related guidance for public cloud environments where PII is processed.

Its focus can be summarized as:

PII
      ↓
Public Cloud
      ↓
Privacy Responsibilities
      ↓
Cloud Controls
      ↓
Evidence & Assurance

It helps organizations establish clearer expectations for how personal information should be protected in cloud services.

2. Why Cloud Privacy Is Different

Traditional environments may keep PII within organizational infrastructure.

Cloud environments introduce additional parties and processing locations.

Example:

Customer
      ↓
Cloud Provider
      ↓
Subprocessor
      ↓
Support Personnel
      ↓
Multiple Regions

This creates additional privacy risk.

3. Privacy Questions in Cloud

Before approving a cloud service, GRC should ask:

What PII is processed?

Why?

Where?

By whom?

For how long?

Under whose instructions?

Who else receives it?

How is it deleted?

What happens during an incident?

These questions should be answered before sensitive information is migrated.

4. PII

Personally Identifiable Information generally refers to information relating to an identifiable individual.

Examples may include:

Name

Email Address

Phone Number

Employee ID

Customer Identifier

IP Address

Government Identifier

Financial Information

The precise legal definition depends on applicable privacy law.

5. PII Is Context Dependent

Example:

Value:
10.10.1.25

In one context, this might be infrastructure data.

In another context, an IP address may be linked to an identifiable user.

GRC should therefore work with privacy/legal teams.

6. Public Cloud Privacy Roles

A simplified model often includes:

Customer / Organization
      ↓
Determines Purpose & Use

Cloud Provider
      ↓
Processes PII

Subprocessor
      ↓
Supports Provider Processing

Exact legal roles depend on applicable law and contractual arrangements.

7. Controller Concept

In many privacy regimes, the controller determines the purposes and means of processing personal information.

Typical responsibilities may include:

Why Data Is Collected

What Data Is Collected

How Long It Is Needed

Who May Receive It

The cloud customer may often act in this type of role.

8. Processor Concept

A processor generally processes PII on behalf of the controller.

Example:

Customer
      ↓
Uses SaaS Provider
      ↓
Provider Processes Customer PII

The provider should operate according to agreed instructions and contractual commitments.

9. Subprocessor

A cloud provider may engage other organizations.

Example:

Cloud Customer
      ↓
Primary SaaS Provider
      ↓
Email Provider
Monitoring Provider
Hosting Provider

These additional parties may act as subprocessors.

Their involvement should be understood and governed.

10. Why Privacy Roles Matter

Responsibilities affect:

Privacy notices.
Contracts.
Data subject rights.
Incident notification.
Retention.
Deletion.
Cross-border transfer.
Subprocessor governance.

Unclear roles create compliance risk.

11. Build a Cloud PII Inventory

A PII inventory should identify:

Data Category

Business Purpose

Cloud Service

Owner

Region

Retention

Subprocessor

Example:

PII	Cloud Service	Purpose	Region	Owner
Customer Name	SaaS Platform	Account Management	EU	Product
Employee Email	HR SaaS	HR Operations	EU	HR
Support Data	Support SaaS	Customer Support	US	Support

12. Why PII Inventory Matters

You cannot protect or govern information if you do not know where it exists.

Without inventory:

PII
      ↓
Unknown Cloud Services
      ↓
Unknown Regions
      ↓
Unknown Retention
      ↓
Privacy Risk

13. Data Discovery

Organizations may identify PII using:

Data inventories.
Application reviews.
Data classification.
Data discovery tools.
Privacy assessments.
Process interviews.

Automated discovery can help, but business context is still needed.

14. Purpose Limitation

PII should be processed only for defined and authorized purposes.

Example:

Collected:
Customer account administration

Not Automatically Permitted:
Advertising
Analytics
AI training

Additional processing should be evaluated against contractual and legal requirements.

15. Purpose Register

Document:

Data	Purpose	System	Owner
Customer Email	Account Login	SaaS	Product
Employee Address	Payroll	HR SaaS	HR

This supports privacy traceability.

16. Processing Instructions

Where a cloud provider acts on behalf of a customer, processing should align with agreed customer instructions.

Examples may include:

Store Data in Approved Region

Process Only for Contracted Service

Delete Data on Termination

Restrict Subprocessor Use

These instructions should ideally be reflected in contract terms.

17. Unauthorized Processing Risk

Example:

Customer uploads employee data
      ↓
Provider uses data for unrelated analytics

This may create contractual and privacy concerns.

Purpose limitation helps reduce this risk.

18. Data Minimization

Collect and process only information necessary for the intended purpose.

Weak approach:

Collect Everything

Better:

Purpose
      ↓
Minimum Necessary PII

This reduces privacy exposure.

19. Example Data Minimization

For newsletter signup:

Necessary:

Email Address

Potentially unnecessary:

Passport Number

Date of Birth

Home Address

GRC should challenge unnecessary data collection.

20. Cloud Service Privacy Assessment

Before adoption, evaluate:

PII Processed

Purpose

Data Location

Security

Subprocessors

Retention

Deletion

Incident Notification

Contract Terms

This can be part of vendor onboarding.

21. Cloud Provider Transparency

Customers should understand how the provider processes PII.

Relevant information may include:

Processing Locations

Subprocessors

Security Measures

Deletion Process

Incident Process

Government Request Handling

Transparency supports risk decisions.

22. Data Location

Organizations should know where PII is stored and processed.

Example:

Primary Region:
Frankfurt

Backup Region:
Dublin

Support Access:
India

All locations may matter for privacy analysis.

23. Data Residency

Residency refers to where information is stored or processed.

Cloud privacy requirements may restrict:

Country

Region

Backup Location

Support Location

These should be validated against legal and contractual obligations.

24. Data Sovereignty

Data sovereignty considers the laws and jurisdictions that may apply to the information.

This may depend on:

Data Location

Customer Location

Provider Entity

Subprocessor Location

Government Jurisdiction

This is more complex than simply selecting a cloud region.

25. Cross-Border Transfers

A public cloud architecture may involve:

Customer in Country A

Data stored in Country B

Support accessed from Country C

GRC should identify applicable transfer requirements.

26. Cross-Border Transfer Register

Create:

Data	Source	Destination	Provider	Basis / Requirement

This helps privacy teams track transfers.

27. Provider Support Access

An important question:

Where can provider personnel access customer PII from?

Storage region may not be the only relevant location.

Example:

Data Stored:
EU

Support Access:
Global

This should be evaluated.

28. Subprocessor Governance

Maintain visibility into cloud-provider subprocessors.

For each, record:

Subprocessor

Service

Purpose

Location

Data Access

Review Status

29. Subprocessor Register

Example:

Subprocessor	Function	Region	PII Access
Hosting Provider	Infrastructure	EU	Yes
Email Provider	Notifications	US	Limited
Monitoring Provider	Telemetry	EU	Possible

30. Subprocessor Change Management

Cloud providers may add or change subprocessors.

Organizations should define how these changes are reviewed.

Workflow:

Provider Notification
      ↓
GRC / Privacy Review
      ↓
Risk Assessment
      ↓
Accept / Escalate

31. Subprocessor Risk

Risks may include:

Unknown Processing Location

Weak Security

Different Legal Jurisdiction

Insufficient Contractual Protection

Subprocessors should not become invisible fourth parties.

32. PII Disclosure

Personal information should not be disclosed without appropriate authority.

Examples of disclosure include:

Customer Request

Legal Requirement

Law Enforcement Request

Subprocessor Sharing

Support Access

Disclosure processes should be controlled.

33. Disclosure Register

Where appropriate, maintain:

Request

Requester

Legal Basis

Data Disclosed

Approver

Date

This supports accountability.

34. Government Requests

Cloud providers may receive government or law-enforcement requests.

Customers should understand, where applicable:

Provider notification commitments.
Legal limitations on notification.
Transparency practices.
Jurisdiction exposure.

These are important during provider due diligence.

35. PII Access Control

Cloud PII access should follow:

Need to Know

Least Privilege

Role-Based Access

Strong Authentication

Administrative access should be especially restricted.

36. Human Access to PII

Maintain visibility into:

Customer Administrators

Support Staff

Provider Personnel

Subprocessor Personnel

Not every employee should have access.

37. Privileged Privacy Access

Example:

Database Administrator
      ↓
Production PII

Controls may include:

PAM

Temporary Access

Approval

Logging

Monitoring

38. Workload Access to PII

Applications also access PII.

Govern:

Service Accounts

Managed Identities

API Credentials

Database Roles

Machine identities should also follow least privilege.

39. PII Logging

Access to sensitive personal information may require logging.

Useful events include:

Record Access

Export

Deletion

Administrative Change

Bulk Download

Logging supports investigation and accountability.

40. Avoid Excessive PII in Logs

Logs themselves can become privacy risks.

Example:

Application Log:
Full customer passport number

This may unnecessarily duplicate sensitive PII.

Prefer:

Masked or limited identifiers

where appropriate.

41. Encryption

PII should be protected appropriately in transit and at rest based on risk and applicable requirements.

Consider:

Encryption at Rest

Encryption in Transit

Key Management

Certificate Management

42. Key Ownership

Possible models:

Provider-Managed

Customer-Managed

Externally Managed

Higher-risk PII may justify stronger customer key control.

43. Backup Privacy

Backups may contain PII.

Therefore:

Primary Data Deleted

does not automatically mean:

All PII Deleted

Backups and replicas should be included in retention/deletion analysis.

44. Retention

PII should not be retained indefinitely without justification.

Define:

Data Category

Retention Period

Reason

Owner

Deletion Method

45. Retention Schedule

Example:

PII	Retention	Reason
Customer Account Data	Contract + defined period	Service
Employee Records	Legal requirement	HR
Support Logs	12 months	Support / Security

Values should reflect actual legal and business requirements.

46. Cloud Retention Configuration

Contractual retention alone is insufficient if the cloud service is incorrectly configured.

Example:

Policy:
Delete after 12 months

SaaS Setting:
Retain forever

This is a control failure.

47. Secure Deletion

Deletion should consider:

Primary Data

Replicas

Snapshots

Backups

Caches

Temporary Files

The exact process depends on the service.

48. Deletion Workflow

Deletion Trigger
      ↓
Validate Authority
      ↓
Delete Primary Data
      ↓
Propagate Deletion
      ↓
Update Backup Lifecycle
      ↓
Record Completion

49. Provider Deletion Capability

Before onboarding a cloud provider, ask:

Can the provider delete data?

How quickly?

What about backups?

Can deletion be verified?

These should be contractual considerations.

50. Termination & Cloud Exit

At contract termination:

Export Required Data
      ↓
Revoke Access
      ↓
Delete PII
      ↓
Disable Integrations
      ↓
Obtain Confirmation

Privacy must be included in offboarding.

51. Data Subject Rights Support

Depending on applicable law, individuals may have rights involving:

Access

Correction

Deletion

Restriction

Portability

Cloud systems should support the customer’s ability to meet relevant obligations.

52. Access Request Workflow

Example:

Individual Request
      ↓
Identity Verification
      ↓
Locate Data
      ↓
Retrieve Data
      ↓
Review
      ↓
Respond

Cloud data inventories make this process easier.

53. Data Location & Rights

PII may exist across:

Primary Database

Support Platform

Backup

Analytics Platform

SaaS Integrations

A rights request may require searching multiple systems.

54. Privacy Incident

A privacy incident may involve:

Unauthorized Access

Wrong Recipient

Data Exposure

Loss

Unauthorized Disclosure

Improper Deletion

Not every privacy incident is a cyberattack.

55. Shared Incident Responsibility

Provider:

Detect Provider-Side Event
Contain Provider Environment
Notify Customer as Agreed

Customer:

Assess Impact

Determine Affected Individuals

Coordinate Legal / Privacy Response

Meet Notification Obligations

This is a shared process.

56. Incident Notification Requirements

Contracts should define:

Notification Trigger

Timeline

Communication Method

Required Information

Ongoing Updates

Customer notification timelines may depend on provider speed.

57. Privacy Incident Evidence

Maintain:

Incident Record

Data Impact

Affected Systems

Affected Individuals

Provider Communications

Decision Log

Notification Evidence

58. Cloud Privacy Risk Register

Privacy risks may include:

Unauthorized PII Access

Incorrect Region

Excessive Retention

Uncontrolled Subprocessor

Failed Deletion

Data Leakage

Unsupported Rights Request

Delayed Incident Notification

These should be incorporated into enterprise risk management.

59. Privacy Risk Statement Example

There is a risk that customer PII may be processed by an unapproved cloud subprocessor in an unauthorized jurisdiction, resulting in contractual and privacy compliance exposure.

This is more useful than:

Risk:
Privacy

60. Privacy Responsibility Matrix

Create:

Control Area	Customer	Provider	Shared
Processing Purpose	✓
Data Storage			✓
PII Access			✓
Retention Configuration	✓
Provider Deletion		✓
Incident Handling			✓
Subprocessor Disclosure		✓
Rights Fulfilment	✓		Shared support

61. Customer Responsibility

The customer may remain responsible for:

Selecting Appropriate Service

Defining Purpose

Classifying PII

Configuring Access

Defining Retention

Selecting Regions

Managing Requests

62. Provider Responsibility

Provider responsibilities may include:

Operating Service Securely

Following Agreed Processing Terms

Managing Provider Personnel

Managing Subprocessors

Supporting Deletion

Providing Transparency

63. Shared Responsibilities

Examples:

Security Incident

Data Protection

Access Control

Deletion

Data Location

Business Continuity

Roles should be explicit.

64. Cloud Privacy Contracts

Review agreements such as:

Master Service Agreement

Data Processing Agreement

Privacy Addendum

Security Schedule

Subprocessor Terms

These establish operational obligations.

65. Data Processing Agreement

A DPA may address:

Processing Purpose

Data Categories

Security Measures

Subprocessors

Incident Notification

Deletion

Audit Rights

Transfer Requirements

GRC should coordinate with Legal/Privacy.

66. Contract-to-Control Mapping

Example:

Contract:
Delete customer PII at termination
      ↓
Control:
Cloud Data Deletion
      ↓
Evidence:
Deletion Confirmation

This makes obligations operational.

67. Privacy Notice Alignment

The organization’s privacy notice should align with actual cloud processing where applicable.

If the notice says:

Data remains in EU

but architecture moves information globally:

Compliance Risk

Architecture and privacy commitments should remain aligned.

68. Privacy by Design

Privacy should be considered during system design.

Example:

New Cloud Application
      ↓
Identify PII
      ↓
Assess Purpose
      ↓
Minimize Data
      ↓
Select Region
      ↓
Define Retention
      ↓
Design Access

Privacy should not be added only after deployment.

69. Privacy Impact Assessment

Higher-risk processing may require a formal privacy assessment.

Areas may include:

Data

Purpose

Individuals

Risk

Provider

Region

Subprocessors

Security

Mitigations

Exact legal requirements vary by jurisdiction.

70. Privacy Control Library

Create enterprise controls.

Example:

PRIV-001
Cloud PII Inventory

Control statement:

All production cloud services processing PII must be recorded in the approved Cloud PII Inventory, including data category, business purpose, owner, provider, processing location, and retention requirement.

71. PRIV-002 — Purpose Limitation

PII processed through cloud services must be limited to approved business purposes documented by the relevant data owner and privacy function.

72. PRIV-003 — Approved Processing Locations

Cloud services processing regulated PII must use approved processing and storage locations consistent with applicable legal, contractual, and business requirements.

73. PRIV-004 — Subprocessor Governance

Critical cloud providers processing PII must maintain documented subprocessor information, and material subprocessor changes must be reviewed for privacy and security impact.

74. PRIV-005 — PII Access

Access to cloud-hosted PII must be restricted to authorized users and workloads based on documented business need and least privilege.

75. PRIV-006 — PII Retention

Cloud-hosted PII must be retained only for approved periods defined in the organization’s retention schedule and implemented within relevant cloud services.

76. PRIV-007 — Cloud PII Deletion

PII must be securely deleted from cloud services when retention expires, the processing purpose ends, or an authorized deletion request is approved, subject to legal and contractual requirements.

77. PRIV-008 — Privacy Incident Notification

Cloud providers processing PII must be contractually required to notify the organization of qualifying privacy or security incidents within agreed timelines sufficient to support organizational response obligations.

78. PRIV-009 — Rights Request Support

Cloud services processing PII must provide sufficient search, export, correction, and deletion capabilities to support applicable individual-rights processes.

79. PRIV-010 — Privacy Provider Assurance

Cloud providers processing sensitive or regulated PII must undergo periodic privacy and security assurance reviews based on risk.

80. Control Ownership

Example:

Control	Owner
PRIV-001	Privacy / GRC
PRIV-002	Data Owner
PRIV-003	Privacy / Cloud Governance
PRIV-004	Third-Party Risk
PRIV-005	IAM
PRIV-006	Data Governance
PRIV-007	Application Owner
PRIV-008	Legal / Privacy
PRIV-009	Privacy Operations
PRIV-010	GRC

81. Control Evidence

Examples:

Control	Evidence
PII Inventory	Inventory Export
Purpose Limitation	Processing Register
Data Location	Cloud Region Configuration
Subprocessor Review	Assessment Record
Access Control	IAM Report
Retention	Retention Configuration
Deletion	Deletion Logs
Incident Notification	Contract + Incident Records

82. Cloud PII Evidence Matrix

Create:

Control
      ↓
Evidence
      ↓
Owner
      ↓
Frequency
      ↓
Retention

This supports privacy audits.

83. Provider Privacy Assurance

Review evidence such as:

ISO/IEC 27018 Certification / Attestation

Privacy Documentation

Security Reports

Subprocessor List

DPA

Data Location Documentation

Do not rely solely on marketing claims.

84. Certification Scope Review

If a provider claims ISO/IEC 27018 alignment or certification, review:

Which Service?

Which Legal Entity?

Which Locations?

Which Processing Activities?

Which Period?

Scope matters.

85. Provider Assurance Exceptions

If provider assurance identifies privacy weaknesses:

Finding
      ↓
Customer Impact
      ↓
Risk Assessment
      ↓
Treatment

Do not simply archive the report.

86. Privacy Monitoring

Useful metrics may include:

PII Cloud Services Inventoried

Approved Regions

Overdue Provider Reviews

Subprocessor Changes

Deletion Requests

Privacy Incidents

Retention Exceptions

87. Privacy KPI Example

KPI:
Percentage of cloud services processing PII
with completed privacy assessment

Target:

100%

88. Privacy KRI Example

KRI:
Number of cloud services processing PII
without a documented approved processing location

Tolerance:

89. Continuous Privacy Governance

Cloud services change.

Therefore monitor:

New Services

New Regions

New Data Categories

New Subprocessors

New Integrations

New Processing Purposes

Privacy assessments should not be performed only at onboarding.

90. Privacy Change Trigger

Example:

Existing SaaS
      ↓
New AI Analytics Feature
      ↓
New PII Processing Purpose
      ↓
Privacy Reassessment

Cloud-service feature changes can materially alter privacy risk.

91. AI Processing Example

Suppose a cloud provider adds:

AI Assistant

Questions:

Does it process PII?

Is customer data used for model training?

Which provider processes it?

Where?

Can feature be disabled?

This should trigger privacy review.

92. Cloud Privacy Audit

An auditor may examine:

PII Inventory

Cloud Service Inventory

Privacy Assessments

DPA

Subprocessor Register

Retention

Deletion

Access

Incident Records

93. Audit Walkthrough — SaaS

Auditor selects:

HR SaaS

Ask:

What PII is stored?

What is the purpose?

Where is it stored?

Who accesses it?

Which subprocessors exist?

How long is data retained?

How is deletion performed?

94. Audit Walkthrough — Terminated Employee

Trace:

Employment Termination
      ↓
HR Account Disabled
      ↓
Records Retained Per Schedule
      ↓
Expired Records Deleted

Verify cloud configuration aligns with policy.

95. Audit Walkthrough — Customer Deletion

Trace:

Authorized Request
      ↓
Application Data Located
      ↓
Deletion
      ↓
Downstream Services
      ↓
Backups / Lifecycle
      ↓
Evidence

96. Privacy Gap Example

Requirement:

Critical SaaS providers must disclose subprocessors.

Current state:

Provider subprocessor list
not reviewed for 18 months.

Result:

Control Gap

Treatment:

Complete review
+
Establish annual review
+
Subscribe to provider change notification

97. Privacy Gap Register

Use:

Gap	Control	Risk	Owner	Target
PG-01	Data Location	Residency	Privacy	Q4
PG-02	Subprocessor Review	Vendor Privacy	GRC	Q4
PG-03	Retention	Excessive Storage	Data Owner	Q1

98. Common ISO/IEC 27018 Mistakes

Mistake 1 — Treating Privacy as Only Legal’s Responsibility

Cloud teams and data owners also have responsibilities.

Mistake 2 — No PII Inventory

Organizations cannot trace personal data.

Mistake 3 — Storage Region Equals Entire Data Location

Support and subprocessors may be elsewhere.

Mistake 4 — Provider Certification Assumed to Cover Everything

Customer configuration still matters.

Mistake 5 — No Subprocessor Governance

Fourth-party risk remains invisible.

Mistake 6 — Retention Policy Exists but Cloud Settings Retain Forever

Policy and implementation conflict.

Mistake 7 — Deletion Covers Primary Database Only

Backups and downstream services remain.

Mistake 8 — PII Included in Logs Unnecessarily

The security system itself increases privacy risk.

Mistake 9 — Cloud Feature Changes Not Reassessed

New processing may appear silently.

Mistake 10 — Privacy Incidents Managed Only as Cybersecurity Events

Privacy consequences may require separate assessment.

99. Practical Activity — Build Cloud PII Inventory

Create:

01 Cloud PII Inventory

Use:

PII Category	Service	Purpose	Region	Owner	Retention

Include at least:

Customer information.
Employee information.
Support information.
Authentication information.

100. Practical Activity — Build Privacy Responsibility Matrix

Create:

02 Privacy Responsibility Matrix

Cover:

Purpose

Access

Security

Subprocessors

Location

Retention

Deletion

Incidents

Rights Requests

101. Practical Activity — Build Cloud Processor Assessment

Create:

03 Cloud Processor Privacy Assessment

Review:

Data processed.
Processing purpose.
Locations.
Security.
Subprocessors.
Retention.
Deletion.
Incident notification.
Contract.

102. Practical Activity — Build Data Location Register

Create:

04 Cloud Data Location Register

Use:

Service	Primary Region	Backup	Support	Subprocessor

103. Practical Activity — Build Subprocessor Register

Create:

05 Cloud Subprocessor Register

Use:

Provider	Subprocessor	Service	Location	Data Access	Status

104. Practical Activity — Build Privacy Control Mapping

Create:

06 ISO 27018 Privacy Control Mapping

Map:

Privacy Risk
      ↓
Privacy Requirement
      ↓
Enterprise Control
      ↓
Owner
      ↓
Evidence

105. Practical Activity — Build Evidence Checklist

Create:

07 ISO 27018 Evidence Checklist

Include:

PII inventory.
Data processing agreements.
Processing purposes.
Data-location evidence.
Subprocessor information.
IAM evidence.
Retention configuration.
Deletion evidence.
Privacy assessments.
Incident records.
Rights-request support.
Provider assurance.

106. Privacy Assessment Checklist

Before approving a cloud service processing PII:

Business owner identified.
PII identified.
Processing purpose documented.
Data minimization considered.
Controller/processor roles understood.
Provider privacy terms reviewed.
DPA reviewed.
Primary data location known.
Backup location known.
Support locations considered.
Subprocessors reviewed.
Cross-border transfers assessed.
Access controls defined.
Encryption requirements defined.
Retention defined.
Deletion capability validated.
Rights-request support validated.
Incident-notification process understood.
Provider assurance reviewed.
Privacy risk accepted or treated.

107. GRC Analyst Responsibilities

A GRC professional supporting ISO/IEC 27018 may:

Maintain cloud PII inventories.
Coordinate processor assessments.
Review privacy-control requirements.
Maintain data-location registers.
Track subprocessors.
Map privacy requirements to controls.
Review retention implementation.
Validate deletion procedures.
Review provider privacy assurance.
Support privacy risk assessments.
Coordinate privacy evidence.
Support audits.
Track remediation.
Work with Legal and Privacy on applicable requirements.

GRC connects:

Privacy

Legal

Cloud

Security

Procurement

Data Owners

Providers

Audit

108. ISO/IEC 27018 Maturity Model

Level 1 — Reactive

Cloud PII locations unknown

Level 2 — Documented

PII Inventory

DPA

Provider Reviews

Level 3 — Governed

Data Locations

Subprocessor Reviews

Retention

Deletion

Level 4 — Integrated

Privacy Risk

Cloud Controls

Evidence

Audit

Level 5 — Continuous Privacy Assurance

Automated Discovery

Continuous Data Location Monitoring

Automated Retention

Continuous Provider Monitoring

109. ISO/IEC 27018 Mindset

For every cloud service processing PII, ask:

What PII is processed?

Why is it needed?

Who determines the purpose?

Who processes it?

Where is it stored?

Where can it be accessed from?

Which subprocessors are involved?

Who can access the PII?

How long is it retained?

How is it deleted?

Can we support individual rights?

How are privacy incidents communicated?

What evidence proves these controls?

If these questions can be answered clearly, cloud privacy becomes significantly easier to govern.

Key Takeaways

ISO/IEC 27018 strengthens privacy protection for PII processed in public-cloud environments.
It complements ISO/IEC 27001 and cloud-security guidance such as ISO/IEC 27017.
Cloud privacy requires clear understanding of customer, provider, and subprocessor responsibilities.
Organizations should maintain an inventory of cloud-hosted PII.
Processing purposes should be documented and limited.
Data minimization reduces privacy exposure.
Storage region alone does not fully describe data location.
Cross-border processing, support access, and subprocessors should be evaluated.
PII access should follow least privilege and strong authentication.
Retention requirements should be implemented in cloud configuration, not just policy.
Deletion should consider primary data, replicas, backups, and downstream systems.
Cloud services should support applicable individual-rights processes.
Privacy incidents require coordination between provider, customer, Legal, Privacy, and Security.
Provider assurance should be reviewed for scope and applicability.
Privacy controls should connect to risk, contracts, ownership, evidence, and audit.
GRC plays a central role in translating cloud privacy obligations into operational controls.

Knowledge Check

Before continuing, make sure you can answer:

What is the purpose of ISO/IEC 27018?
How does it relate to ISO/IEC 27001?
How does it differ from ISO/IEC 27017?
What is PII?
Why is a Cloud PII Inventory important?
What is purpose limitation?
What is data minimization?
What is a processor?
What is a subprocessor?
Why should subprocessor changes be reviewed?
Why does cloud storage region not provide the complete location picture?
What is data residency?
Why are cross-border transfers important?
Why should PII access be logged?
Why should PII be minimized in logs?
Why are retention policies insufficient without configuration?
What should secure deletion consider?
How can cloud providers support individual-rights requests?
What privacy incident responsibilities are shared?
What role does GRC play in ISO/IEC 27018 implementation?

What’s Next?

➡️ Next: 05 — Cloud Provider Responsibilities

In the next lesson, you will move from privacy controls into a deeper examination of what enterprise organizations should expect from their cloud service providers.

You will learn how to evaluate provider responsibilities across:

Physical Infrastructure
        ↓
Platform Security
        ↓
Tenant Isolation
        ↓
Provider IAM
        ↓
Security Monitoring
        ↓
Incident Response
        ↓
Service Resilience
        ↓
Data Protection
        ↓
Privacy
        ↓
Subprocessors
        ↓
Provider Assurance
        ↓
Cloud Exit

You will also build practical GRC artifacts including a Cloud Provider Responsibility Matrix, Provider Assurance Register, Cloud Security Due Diligence Checklist, Provider Control Evidence Map, and Cloud Provider Risk Review.