We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

FAQGlobalISO/IEC 27018

ISO/IEC 27018 FAQ Customer Instructions

define the purposes and operations the is authorized to perform; they should be specific enough to operate, change, and audit.

The current edition is ISO/IEC 27018:2025; the detailed control explanations here use the prior 2019 edition and should be checked against the edition named in a contract or assurance report. ISO/IEC 27018 is voluntary guidance, while applicable law and contracts can impose separate or stricter duties.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
5 sections3 primary sources
Overview

set the purposes and authorized processing for a . They may be expressed through the contract, service configuration, or an authorized request, but the provider should be able to identify who issued the instruction, what service and PII it covers, the objective and time frame, and whether it changes the agreed processing.

Search this module

Find a question or answer quickly

5 of 5 questions
Question 1

What counts as a customer instruction?

Under ISO/IEC 27018:2019, instructions to a can be contained in the contract and can include the service objective and time frame. An order, customer-controlled configuration, authenticated support request, or approved change can implement that contract when the authorized channel, requester, service, PII, operation, purpose, and duration are clear.

A processor may choose technical methods needed to deliver the customer's purpose without an express instruction for every implementation detail. For example, the provider may allocate processing resources to use network capacity efficiently. The method must remain consistent with the customer's general instructions, follow the relevant privacy principles when it collects or uses PII, and never introduce an independent processing purpose.

  • Define which customer roles and channels can issue instructions and how the provider authenticates them.
  • Reject or clarify a request that conflicts with the contract, exceeds the requester's authority, lacks a defined service or purpose, or introduces unsupported processing.
  • Escalate an instruction that appears to conflict with applicable law; for GDPR-covered processing, Article 28 requires the processor to inform the controller immediately if, in its opinion, an instruction infringes the GDPR or other Union or Member State data-protection law.
Question 2

What evidence should show instructions were followed?

Keep the instruction, requester identity and authority, receipt and completion times, affected service and PII, operation, purpose and time frame, provider action, configuration or ticket evidence, approvals, exceptions, and downstream subprocessor effects.

Link the instruction to the applicable contract version and retain change history. Logs should show what the provider did without exposing another customer's information or retaining PII longer than the defined logging purpose requires.

  • Retain the signed contract baseline, authorized-role register, authenticated request or configuration history, execution log, and completion or rejection record.
  • Record why a request was rejected, clarified, or escalated and who approved the outcome.
  • Link a changed purpose, retention period, processing country, or subprocessor to the contract and control records it affects.
Recommended next step

Connect each instruction to authority and execution

Record the requester, authority, contract version, service, purpose, operation, execution evidence, exception, and downstream subprocessor effect.

Assessment workflow
Open Assessment Autopilot for ISO/IEC 27018

Assign instruction validation, execution, rejection, escalation, evidence, and baseline-review tasks.

Explore next step
Talk to Sorena
Talk through implementation

Review your current scope, evidence gaps, and next implementation steps.

Explore next step
Question 3

Who approves ambiguous or changed instructions?

The customer identifies authorized instructing roles. The provider's service owner validates operational scope; privacy and legal assess purpose, role, and legal conflicts; security reviews changes to access or controls; supplier management handles subprocessor effects.

Do not treat silence, an informal message from an unknown requester, or a provider's own product goal as a customer instruction. Resolve ambiguity before processing outside the established baseline.

  • Name the service owner who validates scope, the privacy or legal owner who handles purpose and legal conflicts, and backups for both roles.
  • Keep requester authentication and operational feasibility separate from approval of a changed purpose, retention period, or service commitment.
  • Store clarification, rejection, escalation, and approval records with the instruction history rather than in disconnected email threads.
Question 4

When should instructions be reviewed?

Review for new purposes, features, data, users, locations, subprocessors, support access, retention, deletion, or provider use that could turn instructed processing into own-purpose processing.

Also review when the authorized customer roles, instruction channels, contract version, or responsibility split changes. Update the baseline before accepting new instructions.

  • Set a periodic baseline review and trigger an immediate review for a new purpose, feature, data category, location, subprocessor, or retention rule.
  • Update the contract, authorized-role register, request channels, service configuration, operating procedure, and evidence map when the baseline changes.
  • Block or escalate instructions that remain outside the approved baseline; do not record an unsupported purpose as ordinary risk acceptance.
Question 5

Questions and answers

What should cover under ISO/IEC 27018?

It should identify the authorized requester, processing purpose, affected service and PII, permitted operations, time frame, and any relevant location, subprocessor, retention, return, or deletion condition. The contract and configured service can establish a standing instruction; later requests should remain within that baseline or follow the approved change process.

What evidence usually proves is current?

Keep the authenticated instruction, requester authority, applicable contract version, ticket or configuration change, provider action, approval and exception record, completion result, and any downstream subprocessor action. Evidence should identify the service and date rather than repeat the policy.

Who should approve decisions?

The customer defines who may instruct the provider. The provider's service owner validates scope, while privacy, legal, security, and supplier owners review purpose, legal conflicts, control changes, and subprocessor effects as needed.

When should be reviewed?

Review instructions when purposes, service features, PII, locations, subprocessors, support access, retention, deletion, authorized customer roles, instruction channels, contract terms, or the provider-customer responsibility split changes.

Primary sources

References and citations

GDPR consolidated text
eur-lex.europa.eu
Referenced sections
  • Binding EU data protection regulation used for ISO/IEC 27018 comparison.
"protection of natural persons with regard to the processing of personal data"
ISO/IEC 27018:2019 standard page
iso.org
Referenced sections
  • ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.
"Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors"
ISO/IEC 27018:2025 standard page
iso.org
Referenced sections
  • Primary ISO listing for the 2025 edition of ISO/IEC 27018.
"Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors"

Related guides

ISO/IEC 27018 Audit Evidence FAQ

How to assess ISO/IEC 27018 audit evidence by edition, service scope, criteria, audit period, exceptions, and independent assurance.

ISO/IEC 27018 Breach Support FAQ

ISO/IEC 27018 breach support: when a cloud PII processor should notify a customer, what the contract should define, and what incident records to keep.

ISO/IEC 27018 GDPR Overlap FAQ

How ISO/IEC 27018 can support GDPR processor controls without replacing Article 28 terms, controller accountability, transfers, or breach duties.

ISO/IEC 27018 Government Access FAQ

How ISO/IEC 27018 addresses legally binding law-enforcement requests: validation, customer consultation or notice, limited disclosure, and records.

ISO/IEC 27018 PII Return and Deletion FAQ

How to plan and prove PII return, transfer, deletion, anonymization, or archival across live systems, backups, temporary files, and subprocessors.

ISO/IEC 27018 Processor Duties FAQ

What ISO/IEC 27018 expects from a public-cloud PII processor: customer instructions, purpose limits, security, transparency, incident support, and disposal.

Show all related guides (20)

ISO/IEC 27018 Subprocessor Notice FAQ

What an ISO/IEC 27018 subprocessor notice should disclose, when customers should receive it, and what evidence should support consent and objections.

ISO/IEC 27018 Cloud Privacy FAQ

ISO/IEC 27018 FAQ on public-cloud PII processor scope, customer instructions, subprocessors, disclosures, breaches, deletion, audit evidence, and GDPR.

ISO/IEC 27018 DPA Clause Review Workflow

Review cloud data-processing terms for instructions, purpose limits, controls, subprocessors, disclosures, incidents, rights support, and deletion.

ISO/IEC 27018 Government Access Evidence Guide

Build a controlled government-access case record showing request authentication, legal review, notice, approval, minimized disclosure, transfer, and closure.

ISO/IEC 27018 Government Access Evidence Workflow

Triage a government request for customer PII, validate authority, decide notice and challenge options, minimize disclosure, and preserve the decision record.

ISO/IEC 27018 Privacy Control Checklist

A public-cloud PII processor checklist using ISO/IEC 27018:2019 control examples, with owners, evidence, exceptions, and checks against the 2025 edition.

ISO/IEC 27018 Public Cloud PII Processor Scope Guide

Decide whether a service fits ISO/IEC 27018's public-cloud PII processor scope, separate processor and controller activities, and document the boundary.

ISO/IEC 27018 Subprocessor Evidence Guide

Build subprocessor evidence that proves who processed customer PII, where, under which terms and controls, after which notice and approval, and with what exit result.

ISO/IEC 27018 Subprocessor Evidence Workflow

Assess and approve a cloud subprocessor, disclose its use and countries before processing, handle customer objections, and retain operating and exit evidence.

ISO/IEC 27018 Vendor Contract Requirements Guide

Contract guide for ISO/IEC 27018 public-cloud PII processing: scope, instructions, security, subprocessors, disclosures, incidents, rights support, audits, and exit.

ISO/IEC 27018 vs GDPR Comparison

Compare ISO/IEC 27018 cloud-processor guidance with GDPR legal duties, including scope, Article 28 contracts, breaches, transfers, evidence, and assurance limits.

ISO/IEC 27018 vs ISO/IEC 27701 Comparison

Compare ISO/IEC 27018:2025 cloud-processor guidance with the independent ISO/IEC 27701:2025 privacy management system, including scope, evidence, and assurance.

ISO/IEC 27018 vs SOC 2 Privacy Comparison

Compare ISO/IEC 27018 cloud-processor guidance with a SOC 2 examination that includes Privacy, including scope, Type 1 vs Type 2, evidence, and limits.

Using ISO/IEC 27018 for Public-Cloud PII Processing

Decide whether ISO/IEC 27018:2025 applies to a public-cloud PII processor, how it fits an ISMS, what evidence to keep, and which claims the evidence supports.