Write the contract around the real public-cloud service: processing roles, customer instructions, allocated controls, subprocessors, processing countries, disclosures, incidents, evidence, and end-of-service data handling.
ISO/IEC 27018:2025 is the current edition. The detailed clause examples here come from the withdrawn 2019 edition and must be reconciled to the 2025 text. GDPR Article 28 is included only as an EU-law comparison; other jurisdictions and contracts can require different terms.
Structured answer sets in this page tree.
Cited legal and guidance references.
A cloud processing contract should identify each activity in which the provider acts as a , state what it may do with , allocate every shared control, govern changes and incidents, specify the evidence the customer receives, and account for every copy at exit. PII is information that can identify a person or be linked, directly or indirectly, to that person. ISO/IEC 27018 supplies control guidance; applicable law determines which clauses are legally required.
Start with the service boundary and role for each processing purpose. ISO/IEC 27018 covers a public-cloud provider when it processes on behalf of and according to a customer's instructions. A sets the purposes and means of processing; a acts on the controller's behalf and instructions. Processing for the provider's own purposes needs a separate role, purpose, notice, legal, and contract analysis.
For an EU controller-processor relationship, requires a binding written contract or other legal act that states the subject matter and duration, nature and purpose, personal-data types, data-subject categories, and controller rights and obligations. It also requires documented instructions and specified processor duties. Those legal requirements come from the GDPR, not from ISO/IEC 27018.
For any jurisdiction, define instructions precisely enough to govern normal operation and change. Cover enabled features, support access, diagnostic data, locations, transfers, retention, deletion, and what the provider must do if an instruction conflicts with applicable law. Define whether silence, use of a feature, an administrator action, a support ticket, or an API call counts as an instruction, and how the provider authenticates the person issuing it.
Describe minimum technical and organizational measures in a security schedule or other controlled attachment. The 2019 edition said these measures should keep contracted security arrangements in place, prevent independent processing purposes, and not be subject to unilateral reduction by the provider. It also called for equivalent minimum measures in subprocessor contracts.
Avoid a generic promise to use 'appropriate security' without an allocation or verification method. State the control outcome, responsible party, service dependency, evidence available to the customer, notification process for material changes, and remedy when a committed control is not operating.
The 2019 edition called for disclosure of relevant before use, transparency about processing countries, timely notice of intended changes, and a route for the customer to object or terminate. It allowed restricted disclosure under a non-disclosure agreement or on request when public detail would create an unacceptable security risk, provided the customer knew the information was available.
Keep compelled disclosures separate from ordinary subprocessor processing. The 2019 edition called for the provider to reject requests that are not legally binding, consult the customer before disclosure where legally permitted, and record what was disclosed, to whom, when, under what authority, and from which source.
Set measurable assistance duties for requests from individuals, privacy assessments, security reviews, incidents, regulatory enquiries, and customer audits. The 2019 edition said the contract should define the maximum delay for notifying the customer of a qualifying breach; it did not prescribe one universal number. Choose the period from applicable law, customer duties, risk, and operational capability.
Define exit by data location and copy type. Address export format and timing, return or transfer, live deletion, temporary files, replicas, logs, backups, business-continuity copies, support systems, subprocessor copies, anonymization or archival, legal retention exceptions, and the evidence the provider will supply.
Link each negotiated term to an owner, operating procedure, evidence source, exception path, and change trigger.
Convert contract commitments into owned tasks, evidence requests, exceptions, and review checkpoints.
Review your current scope, evidence gaps, and next implementation steps.
Do not let a policy URL or online security schedule change a negotiated protection without control. Define which documents are incorporated, the version or change mechanism, which changes require notice or consent, and the order of precedence when terms conflict.
For an exception, record the affected clause and service, reason, duration, residual risk, compensating control, evidence, approving roles, customer notice or consent if required, and the event that ends or reopens the exception.
"The contract or the other legal act referred to in paragraphs 3 and 4 shall be in writing"
"Contractual agreements need to clearly specify the PII protection responsibilities of all organizations involved"
"Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors"