ISO 27018 FAQ

It is a code of practice for protecting personally identifiable information in public cloud services that act as PII processors. It builds on ISO/IEC 27002 style controls and adds cloud specific guidance for processor obligations.

The practical outcome is a processor control model for instructions, subprocessor management, disclosure handling, breach support, deletion, and customer assurance.

Public cloud providers, SaaS vendors, managed platforms, and hosting services should care when they process personal data on behalf of customers. Privacy teams and procurement teams should also use it to evaluate whether the provider can support processor obligations in practice.

It is especially useful where a provider wants a repeatable answer to customer questions about subprocessors, countries, disclosure requests, incident handling, and deletion.

No. The official ISO listing now shows ISO/IEC 27018:2025 as the current edition, and the ISO/IEC 27018:2019 page is marked withdrawn.

The 2019 text still matters for implementation review because it contains the detailed control themes used in many existing programs, but the current ISO listing should control any claim about the active edition.

A provider is acting as a PII processor when it processes PII for and according to the instructions of the cloud service customer. The distinction depends on the provider not having independent processing objectives for that customer PII.

A provider can still act as a controller for separate data sets, such as account ownership data or its own business records.

It requires that PII processed under contract is not processed for any purpose independent of the customer instruction. That means independent product, marketing, or advertising use is a red flag unless the legal basis and contract structure clearly authorize it.

The standard also says marketing or advertising use should not happen without express consent, and consent should not be made a condition of receiving the service.

It expects disclosure before use, transparent contract treatment, notice of intended changes, and a customer ability to object or terminate. It also expects providers to identify the relevant subprocessor countries and explain how subprocessors are required to meet or exceed the processor's obligations.

This is why a one line statement that subprocessors may change at any time is not enough.

The provider should notify the customer of legally binding disclosure requests unless notice is prohibited, reject requests that are not legally binding, consult the customer where legally permissible, and record disclosures.

Records should capture both the source of the disclosure and the source of the authority for the disclosure.

It expects prompt notice to the relevant cloud service customer when unauthorized access to PII, or to processing equipment or facilities, results in loss, disclosure, or alteration of PII.

The contract should define the maximum notification delay and the information required so the customer can perform its legal assessment and any regulator notification it owes.

The deletion and return policy should address export, transfer, disposal, anonymization, and archiving, and it should explain how PII is erased from all relevant locations, including backup and business continuity storage, once it is no longer needed for the customer's purpose.

The contract should also define the deletion mechanism or commercial standard used, and the retention period before destruction after contract termination.

The standard recommends keeping current and historical policies and procedures for a documented period. In the absence of a specific legal or contractual requirement, it recommends a minimum retention period of five years.

This is especially useful for customer disputes, authority investigations, and proving that older commitments were in force at a specific time.