ISO 27018
cloud PII processor controls and audit guide
ISO/IEC 27018:2019 sets out the obligations a public cloud service provider takes on when it processes personally identifiable information on behalf of customers. It layers on top of ISO 27002 and ISO 27017, adding privacy-specific implementation guidance and an annex of additional PII processor controls. This page covers the structure, the controller and processor responsibility split, and how a workspace records the evidence ISO 27018 expects.
No credit card required. Free plan available forever.
ISO 27018 in context: PII processor obligations for public clouds
ISO/IEC 27018:2019 is the international standard for protecting personally identifiable information (PII) in public cloud services that act as PII processors. It does two things at once: it adds privacy-specific implementation guidance to the ISO 27002 controls when PII is processed in a public cloud, and it sets out an annex of additional obligations derived from the ISO 29100 privacy framework that cloud processors are expected to meet. ISO 27018 is informative on top of ISO 27002 and ISO 27017 rather than normative on its own; certification runs against ISO 27001, with ISO 27018 informing how the cloud PII portion of the audit is structured and evidenced.
The relationship most teams need to keep clear is the layering across the ISO 27001 family. The ISO 27001 framework page covers the management system standard that certifies the ISMS. The ISO 27002 framework page covers the implementation guidance for the 93 ISO 27001 Annex A controls. The ISO 27017 framework page covers the cloud-specific extension. ISO 27018 sits on top of those: it inherits the ISO 27017 cloud guidance and adds the public cloud PII processor obligations that only apply when the cloud workload involves personal data the customer is the controller of. The Statement of Applicability still cites ISO 27001 Annex A; the public cloud PII guidance and the additional annex controls reference ISO 27018 explicitly so the auditor can trace the cloud PII obligation back to the right standard text.
Where ISO 27018 sits in the ISO 27001 family
Three baseline standards underpin ISO 27018, and the SoA needs to read all three together rather than picking one. ISO 27018 cannot be implemented in isolation; it consumes the ISO 27002 control catalogue and the ISO 27017 cloud extensions and extends them with PII-specific obligations.
ISO 27001 (the management system)
The certifiable management system standard. Defines the ISMS, the Statement of Applicability against Annex A, and the audit cycle. ISO 27001 remains the certifiable standard; ISO 27018 informs the cloud privacy portion of that examination but cannot be certified on its own.
ISO 27002 (the control catalogue)
The implementation guidance behind the 93 ISO 27001 Annex A controls. ISO 27018 references ISO 27002 as the baseline catalogue and adds public cloud PII processor obligations on top, rather than restating the entire catalogue.
ISO 27017 (cloud services)
The cloud-specific extension to ISO 27002. ISO 27018 inherits ISO 27017 cloud guidance and the seven CLD controls, then layers the PII processor obligations that only apply when the cloud workload involves personal data on behalf of customers.
The ISO 27018 annex of additional PII processor obligations
ISO 27018 introduces an annex of additional obligations that public cloud PII processors are expected to meet beyond what ISO 27002 and ISO 27017 cover. The annex is structured around the eleven privacy principles in ISO 29100 and translates each principle into operational obligations that apply when the processor is a public cloud service. The list below summarises the obligations a public cloud PII processor takes on under the annex.
Consent and choice
The cloud service provider acts on PII only on documented customer instructions, including transfers to sub-processors and changes to processing scope. The annex requires the contract to record the consent boundary so the public cloud operator does not silently widen its processing of PII against the customer instruction.
Purpose legitimacy and specification
PII processed in a public cloud has a specified purpose tied to the service the customer instructs the provider to deliver. The annex prevents secondary processing for provider-internal product development, training data, or analytics absent an explicit customer instruction; the audit trail records every purpose against which PII has been processed.
Collection limitation
The provider does not collect PII beyond what the customer instruction specifies for the cloud service. The annex pushes the discipline back to the contract and the configuration, so service telemetry, support diagnostics, and provider observability cannot become a side channel for additional PII collection.
Data minimisation
Public cloud processing keeps PII to the minimum necessary for the purpose. The annex obligates the provider to delete or de-identify PII when the processing purpose no longer needs it, and to evidence that minimisation against the contract.
Use, retention, and disclosure limitation
PII is used, retained, and disclosed only as the customer instruction allows. The annex extends ISO 27002 obligations on retention to the cloud setting, with explicit rules for disclosure to law enforcement, government access requests, and any third party outside the customer instruction.
Accuracy and quality
Where the public cloud service produces or modifies PII (extracts, derived records, processed exports), the provider supports the controller in keeping the PII accurate. The annex moves accuracy from a controller obligation alone to a controller/processor shared obligation when the processor is the public cloud service.
Openness, transparency, and notice
The cloud service provider gives the controller transparency about where PII is stored, which sub-processors handle it, what the security model is, and what the breach notification path looks like. The annex turns provider transparency into an audit obligation rather than a marketing claim.
Individual participation and access
The provider supports controller responses to data subject requests (access, rectification, erasure) by exposing the technical means the controller needs. The annex obligates the provider to enable controller fulfilment of GDPR Articles 15 to 22 and equivalent rights regimes; it does not relieve the controller of those obligations.
Accountability
The provider maintains records that demonstrate the public cloud service has met the PII processor obligations the contract sets out, including audit-ready evidence of the controls and any deviations or exceptions. The annex codifies accountability as a documented, reviewable trail rather than a recitation of policy.
Information security
PII in the public cloud is protected with the security controls ISO 27002 and ISO 27017 set out, evaluated against the additional sensitivity that PII carries. The annex draws the boundary between provider-applied security and customer-applied security and obligates both to evidence their portion.
Privacy compliance
The provider establishes, documents, and maintains processes to comply with the privacy obligations the customer contract and applicable law set out. The annex names privacy compliance as a continuing operational obligation rather than a one-off implementation.
Each annex obligation reaches into territory that cloud assessment work touches directly. Identity boundaries, configuration baselines, retention enforcement, and tenant isolation for PII are all evaluated by cloud security assessments that produce findings against the underlying obligations. PII-handling cloud workloads also intersect heavily with sensitive data exposure and cloud bucket misconfiguration findings; the annex obligations make those findings evidence against specific control rows rather than freestanding technical issues.
The customer (controller) and provider (processor) responsibility split
ISO 27018 turns the controller and processor split from a marketing diagram into a documented obligation. The annex requires a clear allocation of responsibilities between the cloud customer (acting as controller) and the cloud service provider (acting as processor) for every PII-relevant obligation. Without that documentation, neither side can demonstrate that its part of the obligation is being met, and the auditor cannot verify the boundary the organisation operates against.
- Provider obligations centre on the public cloud platform: tenant isolation for PII, sub-processor disclosure, breach notification to the customer, encryption at rest and in transit where the contract requires it, deletion or return of PII at contract termination, and the records the controller relies on for accountability.
- Customer (controller) obligations centre on the workload and the contract: lawful basis for processing, data subject communication, consent management, configuration of provider features that affect PII (key management, retention, regional storage), and the contractual instructions the provider acts on.
- Shared obligations live at the boundary the contract sets: incident response timing, configuration baselines, identity and access management, audit logging fidelity, and the breach notification chain. The contract documents which side owns the technical control, the evidence, and the verification step for each.
- Sub-processor obligations flow from the customer instruction through the provider to the sub-processor. The annex requires the provider to flow the same obligations to any sub-processor handling PII; the customer retains the audit right and the contractual remedy if a sub-processor falls short.
The provider attestation pattern most cloud customers consume sits at the boundary between ISO 27018 and other compliance regimes. The SOC 2 framework page covers the trust services criteria that many provider attestations follow, and the GDPR framework page covers the privacy obligations under EU and UK law that ISO 27018 is most often deployed to evidence. ISO 27018 does not replace those regimes; it is the operational layer most often used to evidence the technical and organisational measures the regimes already require.
Building the per-control evidence base for cloud PII
ISO 27018 audit findings most often centre on evidence rather than on control intent. The PII obligation is named in the SoA, the controller and processor roles are documented, and the team can describe what each side does, but the artefact a certification body asks for is either missing, stale, or non-specific to the cloud service in question. The evidence model below is what survives stage 2 and surveillance review.
- Contractual evidence sits in the data processing agreement (DPA) the customer and the provider sign under Article 28 GDPR or the equivalent regime, citing the ISO 27018 annex as the technical and organisational measures basis. The DPA references the standard rather than restating it, so the audit reads from one document to both.
- Provider attestation evidence sits in third-party reports the provider publishes (ISO 27001 + ISO 27018 certificate, ISO 27017 statement of applicability, SOC 2 Type II reports, region-specific compliance reports). The customer holds the attestation reference; the provider audit holds the underlying evidence.
- Customer-controlled evidence sits in the workspace records the customer maintains: configuration baselines for PII-handling cloud services, identity provisioning records, retention policies enforced through the platform, and the assessment findings against PII-handling cloud workloads.
- Cloud penetration test and configuration review findings link back to the relevant ISO 27002 / ISO 27017 / ISO 27018 obligations, so the technological evidence base feeds the control register the auditor walks. The audit trail per finding records who triaged, who validated, and who closed.
- Breach evidence is recorded against the relevant ISO 27018 obligation with the provider notification reference, the controller impact assessment, the data subject notification chain (where applicable under GDPR Articles 33 and 34), and the remediation that followed. The breach record is a load-bearing piece of accountability evidence.
For the technological side of the evidence base, scanner findings against PII-handling cloud assets need to preserve the evidence that turned the detection into a finding. The scanner output deduplication guide covers how to merge findings across cloud scanners without losing the per-source evidence each export carried, and the false positives guide covers the validation discipline that keeps the per-control evidence chain trustworthy when the obligation in question is privacy-sensitive.
How SecPortal aligns to ISO 27018 implementation work
SecPortal is the workspace that holds the engagement, the cloud assessment findings, and the audit trail that the per-control evidence chain references. The platform does not certify the ISMS and is not a substitute for the certification body audit, but it does hold the work the implementation team relies on when building and maintaining the cloud PII evidence base.
- Compliance tracking with workspace-level templates that record per-control status, evidence pointers, and the customer/provider responsibility split each PII-relevant cloud control needs to capture.
- Findings management that links cloud penetration test, configuration review, and scanner output to the specific ISO 27018, ISO 27017, or ISO 27002 control the finding evidences. The audit trail walks from the cloud finding back to the standard text without manual cross-referencing.
- Engagement management that records the work behind cloud assessments where PII is in scope (the scope, the targets, the methodology, the testers, the timeline), so the assessor activity is itself a piece of ISO 27018 evidence.
- AI report generation that produces the narrative compliance summary an internal audit committee or a certification body expects, with the underlying control register and evidence base preserved behind the narrative.
- Activity logs that record every status change, evidence upload, and assignment in the workspace. The log is part of the accountability evidence the annex requires the cloud service to support.
- Continuous monitoring with scheduled scans against verified cloud-hosted endpoints, so the technological evidence behind PII-handling cloud workloads stays current rather than ageing between audit cycles.
For the delivery side of cloud PII assessment work, the page for cloud security consultancies covers the delivery model many ISO 27018 evidence engagements use, and the page for compliance consultants covers the project-driven delivery model that runs ISO 27001 + ISO 27018 readiness work as structured engagements rather than spreadsheet binders.
The certification path for ISO 27018
ISO 27018 cannot be certified on its own. The certifiable obligation is ISO 27001; ISO 27018 informs the public cloud PII portion of the ISO 27001 audit. Certification bodies accredited under the ISO 17021 family scheme typically state ISO 27017 and ISO 27018 alongside ISO 27001 on the certificate when the public cloud and PII scope is in play, with the ISO 27018 reference signalling that the PII processor obligations have been audited as part of the ISO 27001 examination.
- Stage 1 review checks the management system documentation: the scope (which cloud services and which workloads), the ISMS policy, the Statement of Applicability that cites ISO 27001 Annex A controls, and the ISO 27018 references that show how the public cloud PII obligations are addressed. The review is documentary; gaps surface before stage 2 reaches operations.
- Stage 2 audit examines the operational evidence: how each PII-relevant control is implemented, what evidence supports the implementation, and whether the customer/provider responsibility allocation is documented and current. The auditor walks the per-control evidence chain rather than accepting policy alone.
- Surveillance audits in years one and two re-examine a sample of controls and any non-conformities raised at certification. PII-handling cloud controls usually feature in surveillance because the underlying cloud services and sub-processor relationships change faster than the ISMS does.
- Recertification at year three repeats the full stage 1 and stage 2 cycle, with the cloud and PII control set typically expanded if the organisation has moved to additional cloud services or extended the PII processing footprint since initial certification.
Common implementation mistakes
The mistakes below recur across organisations bringing PII-handling cloud workloads into an existing ISMS and across organisations whose providers carry an ISO 27018 attestation but whose customer-side evidence has not kept pace. Each is recoverable with a documented correction; each is hard to recover when discovered at the certification body audit.
- Treating ISO 27018 as a substitute for ISO 27001 or ISO 27002. ISO 27018 layers on top of those baseline standards; certification still runs against ISO 27001 with ISO 27017 and ISO 27018 informing the cloud and PII portions. A Statement of Applicability that cites ISO 27018 without the underlying ISO 27001 Annex A controls fails the audit review.
- Reading the provider ISO 27018 attestation as a discharge of controller obligations under GDPR. The provider attestation covers the processor side of the boundary; the controller still holds the lawful basis, the data subject communication, and the impact assessment obligations the provider cannot discharge.
- Letting the data processing agreement drift from the operational reality of the cloud service. Providers re-cut sub-processor lists, regional configurations, and feature behaviour across releases; a DPA written at contract signing diverges from the operational picture without an explicit refresh discipline.
- Confusing ISO 27017 (cloud services), ISO 27018 (PII in public clouds), and ISO 27701 (privacy information management). Each layers on the others; treating one as covering all three leaves either privacy programme governance or cloud-specific PII processing unsupported.
- Citing ISO 27018 without scoping the cloud services in question. The annex applies where the cloud service processes PII; pasting the reference into the SoA without per-service PII scoping produces an audit gap because the assessor cannot verify which services the obligations apply to.
- Treating data subject access support as a controller-only concern. The annex obligates the provider to expose the technical means controllers need to fulfil access, rectification, and erasure requests; a controller cannot rely on a provider that does not surface those means.
Where ISO 27018 sits alongside other compliance regimes
Most cloud customers carrying PII obligations live with more than one regime, and ISO 27018 is most often deployed to evidence the technical and organisational measures clauses those regimes already require. The cross-walks below cover the regimes that most often layer onto an ISO 27018 implementation rather than replacing it.
- GDPR treats ISO 27018 as a recognised basis for the technical and organisational measures required of processors under Article 32. The annex obligations map closely to the processor accountability clauses in Article 28, and the breach notification chain in Articles 33 and 34 sits naturally on top of the ISO 27018 evidence base.
- ISO 27017 is the cloud-specific baseline ISO 27018 builds on. The seven CLD controls in ISO 27017 stay in scope for any ISO 27018 implementation; the annex extensions layer on the PII-specific obligations rather than replacing the cloud-specific ones.
- SOC 2 is the attestation many cloud providers publish; ISO 27018 customers consume the SOC 2 report as part of the provider evidence chain for the privacy criterion in the trust services framework. The two regimes cover overlapping ground from different sides of the boundary.
- HIPAA treats cloud processors as business associates. The ISO 27018 annex controls map closely to the security and privacy rules behind a HIPAA Business Associate Agreement; the regimes sit alongside rather than replacing each other when protected health information is processed in a public cloud.
- DORA draws on ISO 27001 family controls for ICT third-party risk management evidence and specifically calls out cloud service provider risk management. Where the cloud workload processes PII, ISO 27018 supplies much of the evidence base DORA examinations expect on top of the underlying ISO 27001 + ISO 27017 baseline.
- ISO 27701 is the certifiable privacy information management system extension to ISO 27001. ISO 27018 covers public cloud PII processor obligations; ISO 27701 wraps the wider privacy management system around them. Organisations processing PII in public clouds typically carry both standards in scope rather than choosing between them.
Cloud security work that feeds the ISO 27018 evidence base
Cloud assessment work is the most direct source of evidence for the technological side of ISO 27018. Penetration tests against PII-handling cloud applications, configuration reviews of cloud platform settings that affect PII (key management, retention, regional storage, identity federation), and continuous scanning of verified cloud-hosted endpoints all produce findings that link back to specific ISO 27002, ISO 27017, and ISO 27018 obligations.
For the engagement workflow that runs the cloud assessment from scoping through to delivery, the cloud security assessment workflow covers the operational discipline that turns each assessment into reusable ISO 27018 evidence rather than a single-use report. The cloud security assessment guide covers the methodology that produces the findings the ISMS evidence base inherits, and the remediation tracking workflow covers the closure cycle that turns a PII-handling cloud finding into evidence the control has actually been addressed rather than merely raised.
Scope and limitations
ISO/IEC 27018:2019 is published by the International Organization for Standardization and the International Electrotechnical Commission. SecPortal is the workspace that holds the engagement, the findings, the evidence, and the audit trail; certification under ISO 27001 with the ISO 27018 reference remains the registrant is responsibility, carried out through an accredited certification body. This page describes the structure of the standard and how a workspace-driven programme plays against the public cloud PII processor obligations; the authoritative reference for the obligations remains the published standard text and any subsequent ISO and IEC revisions.
Nothing on this page is legal or audit advice. Decisions about ISO 27001 certification scope, the ISO 27018 cloud PII reference, and the privacy regimes the implementation is intended to evidence (GDPR, HIPAA, regional privacy law) require the involvement of the organisation is data protection officer, privacy counsel, internal audit, and the chosen certification body. The platform supports the underlying work record those roles rely on; it does not substitute for the privacy assessment, the contractual review, or the certification body audit that determines whether the ISMS meets the standard.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Consent and choice
Public cloud PII processors act only on documented controller instructions for the processing of PII, including transfers to sub-processors and changes in scope. The control codifies the consent boundary as a contractual obligation rather than an implicit assumption.
Purpose legitimacy and specification
PII processed in the public cloud has a specified purpose tied to the service the customer instructs. The control prevents secondary processing for provider-internal product development, training data, or analytics absent an explicit customer instruction.
Collection limitation and data minimisation
The provider does not collect PII beyond what the customer instruction specifies, and minimises retention to what the purpose requires. The control extends ISO 27002 retention obligations into the public cloud setting with explicit deletion or de-identification expectations.
Use, retention, and disclosure limitation
PII is used, retained, and disclosed only as the customer instruction allows. The control sets explicit rules for disclosure to law enforcement, government access requests, and any third party outside the customer instruction.
Openness, transparency, and notice
The provider gives the controller transparency about where PII is stored, which sub-processors handle it, what the security model is, and what the breach notification path looks like. The control turns provider transparency into an audit obligation.
Individual participation and access
The provider supports controller fulfilment of data subject rights (access, rectification, erasure) by exposing the technical means the controller needs. The control obligates the provider to enable controller responses without discharging controller responsibility.
Accountability
The provider maintains records that demonstrate the public cloud service has met its PII processor obligations, including audit-ready evidence of the controls and any deviations or exceptions. Accountability is a documented, reviewable trail rather than a recitation of policy.
Evidence ISO 27018 PII obligations without losing the audit trail
Track controller and processor responsibilities per cloud control, attach PII assessment findings, and keep the evidence base ready for surveillance review.
No credit card required. Free plan available forever.