ISO 27018 compliance checklist: practical cloud PII controls

Team working through a cloud privacy review Photo: Unsplash

An ISO 27018 compliance checklist converts cloud privacy principles into owned workflows and retrievable proof. Use it to test how your public cloud service receives instructions, limits PII use, governs subprocessors, handles incidents, and completes deletion.

It should also expose ownership gaps before they affect customers or delay an assessment.

This guide covers:

PII scope, purposes, locations, and roles
Processing agreements and customer instructions
Encryption, access, subprocessor, and breach workflows
Retention, return, deletion, and audit evidence

Related guides:

Checking every privacy detail

GIF via GIPHY

Key takeaways

Role and scope come first. Identify where the service acts as a public cloud PII processor.
Purpose limitation must reach product operations. New uses and features need review against customer instructions.
Transparency requires synchronized records. Agreements, data maps, subprocessor lists, and trust content should match.
Incident and deletion promises need tested workflows. A contract clause alone is not operating evidence.
Evidence should follow the PII lifecycle. Collection, access, transfer, disclosure, retention, return, and deletion all leave different records.

1. Scope PII processing

Define in-scope services, entities, teams, and regions.
Confirm when the provider acts as PII processor and document other roles.
Inventory PII categories, data subjects, purposes, customers, systems, transfers, and subprocessors.
Map active storage, replicas, logs, exports, and backups.
Assign privacy, security, engineering, legal, and support owners.
Define triggers for reviewing the inventory after product or supplier changes.

Inventory field	Why it matters	Typical evidence
Processing purpose	Tests use limitation	Processing record and agreement
Location	Supports customer transparency	Architecture/configuration export
Retention	Drives lifecycle controls	Retention schedule
Subprocessor	Identifies external dependency	Register and diligence
Owner	Creates accountability	Approved inventory

Do not copy a generic data map without validating production architecture. Interview system owners and sample configurations.

2. Control instructions and agreements

Processing terms define subject matter, duration, purpose, data, and party responsibilities as applicable.
Product and support workflows identify valid customer instructions.
Conflicting, unclear, or potentially unlawful instructions have an escalation path.
PII is not used for advertising or unrelated purposes contrary to commitments.
Agreement deviations receive legal, privacy, security, and technical review.
Personnel confidentiality duties and privacy training are documented.
Customer export and assistance capabilities match contract language.

Maintain a requirements-to-control matrix for material contract promises. Legal commonly owns templates; product and engineering confirm capability; privacy monitors changes; support executes customer-facing procedures.

3. Implement safeguards

Access and confidentiality

Access is limited to approved business need.
Privileged roles require MFA and named accounts.
Joiner, mover, and leaver workflows update access promptly.
Access reviews cover production and support tools.
Administrative activity is logged and protected.

Encryption and key management

PII encryption requirements exist for transit and storage.
Configurations are tested against approved baselines.
Key ownership, rotation, access, backup, and revocation are assigned.
Exceptions include risk approval and expiry.
Customer-managed key claims are validated against actual functionality.

Secure operations

Vulnerability, patch, configuration, change, backup, and monitoring workflows cover PII systems.
Tenant isolation and authorization receive security testing.
Production data use in development is prohibited or tightly controlled.
Media and equipment disposal produce records where relevant.

Evidence may include configuration exports, key settings, access reviews, code approvals, scanner results, tests, and remediation tickets.

4. Manage transparency and incidents

Subprocessors

Maintain a current subprocessor register with service, purpose, location, owner, and review date.
Complete privacy and security diligence before onboarding.
Include appropriate terms and flow-down obligations.
Monitor changes and deliver notices according to commitments.
Define a process for customer objections where offered.
Reassess critical subprocessors on a risk-based cadence.

PII incidents

Define privacy-incident criteria and triage.
Map contractual and legal notification decision points.
Assign legal, privacy, security, communications, and customer owners.
Preserve facts, decisions, approvals, and notice records.
Test a cloud PII scenario through tabletop exercises.
Track corrective actions to verified closure.

Notification timing varies by law and agreement. Maintain a decision workflow rather than hard-coding one universal deadline into every procedure.

5. Prove retention and deletion

Retention rules link PII categories and systems to approved periods.
Legal holds suspend deletion in a controlled way.
Customers can retrieve data in the supported format.
Termination removes tenant and administrator access.
Deletion covers primary systems, replicas, and downstream copies.
Backup expiry and isolation are documented.
Completion creates an authorized, dated record.
Sample deletion workflows are tested end to end.

Scenario	Owner	Evidence
Customer export	Support/product	Authorized ticket and export log
Scheduled retention deletion	Data engineering	Job result and monitoring
Contract termination	Privacy operations	Offboarding checklist
Backup expiry	Infrastructure	Policy, configuration, expiry record
Legal hold	Legal/privacy	Approved hold and release

6. Prepare audit evidence

Create an evidence index by control, owner, period, source, and reviewer. Sample normal operations rather than manufacturing new artifacts for the audit. Confirm each sample is in scope, dated, approved, complete, and consistent with policy and agreement.

Run an internal audit that tests both design and operation. Track findings with root cause, corrective action, owner, due date, and effectiveness review. Management review should consider incidents, rights-support metrics, overdue deletions, supplier changes, exceptions, audit results, and resource needs.

ISO 27018 is commonly assessed with an ISO 27001-based management system. Agree on criteria, scope, period, and permitted certificate wording with the certification body.

Run three end-to-end tests

Before the audit, test workflows that cross multiple teams:

A new subprocessor: trace intake, privacy and security diligence, agreement approval, register update, customer notice, and ongoing review.
A suspected PII incident: trace detection, containment, PII impact analysis, legal and contractual decisions, customer communication, and corrective action.
A customer termination: trace authorization, export, access removal, active-data deletion, backup treatment, exceptions, and confirmation.

For each test, record timestamps, decision owners, systems used, missing information, and follow-up actions. A tabletop can test decision logic, but supplement it with technical samples where the outcome depends on configuration or deletion tooling.

Check evidence integrity

Artifacts identify the service, environment, and review period.
Populations are complete and exclusions are explained.
Reviewers are authorized and sufficiently independent.
Removals and remediation are traceable to completion.
Evidence retention matches audit and contractual needs.
Sensitive PII in audit files is minimized and access-controlled.
Automated collections are sampled for correctness.

Finally, reconcile the evidence index with the PII inventory and processing agreements. Every material system and commitment should lead to a control owner and evidence source. Orphan systems indicate scope risk; orphan promises indicate an operational risk that should be resolved before assessment.

Manage ISO 27018 in SecureSlate

SecureSlate helps teams assign privacy controls, automate evidence requests, maintain supplier records, track findings, and reuse validated evidence across privacy and security reviews.

Get started for free: Create your SecureSlate account

FAQ: ISO 27018 compliance

Is every checklist item required?

Applicability depends on role, scope, risk, contracts, and assessment criteria. Document decisions and consult the official standard.

Who should own ISO 27018?

Privacy or GRC commonly coordinates. Engineering, security, legal, procurement, support, and product should own the controls they operate.

What deletion evidence do auditors expect?

Common evidence includes approved requests, workflow logs, backup treatment, access removal, exceptions, and completion records.

Does ISO 27018 replace privacy law compliance?

No. It is control guidance, not a substitute for legal analysis or applicable obligations.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice. Consult qualified legal counsel, privacy professionals, the official standards, and your certification body.