ISO/IEC 27018 Vendor Contract Requirements

Start with the service boundary and role for each processing purpose. ISO/IEC 27018 covers a public-cloud provider when it processes PII on behalf of and according to a customer's instructions. A PII controller sets the purposes and means of processing; a PII processor 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, GDPR Article 28 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 subprocessors 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 PII 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 PII 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.

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.