Introduction: ISO/IEC 27018 and the accountability of cloud processors
ISO/IEC 27018 is the international code of practice that translates data-protection principles into concrete operational controls for public cloud service providers that process personally identifiable information (PII) on behalf of their customers. First published in 2014 and revised in 2019, it sits inside the ISO/IEC 27000 family and is designed to be implemented on top of an established Information Security Management System (ISMS) certified against ISO/IEC 27001 and the controls of ISO/IEC 27002. Its distinguishing feature is perspective: whereas ISO/IEC 27001 protects the organisation's own information assets, ISO 27018 protects the personal data of other people that a cloud provider merely holds and manipulates as a processor. It is, in effect, the world's first widely adopted privacy standard written specifically for the role of the PII processor operating in a public cloud.
For a cloud-native business, ISO 27018 answers a question that customers, regulators and enterprise procurement teams increasingly ask before signing: 'When our customers' personal data lives in your cloud, what stops you from mining it, disclosing it, retaining it forever, or losing it?' The standard provides a defensible, auditable answer. It maps cleanly onto the roles and obligations of data-protection regimes such as the EU GDPR, India's DPDP Act 2023, and sector regimes worldwide, giving the cloud provider a recognised way to demonstrate that it behaves as a trustworthy processor. Certification is achieved as an extension of the ISO 27001 audit scope, so a single accredited certification body can assess ISMS conformity and ISO 27018 privacy controls in one integrated engagement.
Copyright and licensing note
ISO/IEC 27018:2019 is a copyrighted standard published by ISO and IEC. The normative control text, annexes and definitions are protected and must be purchased from ISO, IEC, BIS (in India) or an authorised national standards body. This guide is an original, plain-English interpretation written for audit-readiness. It paraphrases requirements and does not reproduce the licensed control wording. Always obtain a licensed copy of ISO/IEC 27018:2019, together with ISO/IEC 27001:2022 and ISO/IEC 27002:2022, for authoritative control text before an assessment or certification.
What is ISO/IEC 27018
ISO/IEC 27018 is titled 'Information technology - Security techniques - Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors'. It is a sector-specific privacy extension of ISO/IEC 27002. It does two things. First, it provides augmented implementation guidance for a subset of the general ISO/IEC 27002 controls, sharpening them so that they address the specific privacy risks of processing PII in a public cloud. Second, and more importantly, it adds a self-contained set of additional privacy controls, presented in its Annex A, that have no direct equivalent in ISO/IEC 27002 and that exist purely to protect PII principals (the individuals whom the data is about).
The standard is built around the eleven privacy principles of ISO/IEC 29100 (the Privacy Framework): consent and choice; purpose legitimacy and specification; collection limitation; data minimisation; use, retention and disclosure limitation; accuracy and quality; openness, transparency and notice; individual participation and access; accountability; information security; and privacy compliance. ISO 27018 operationalises the subset of these principles that are relevant to a processor. Because a public cloud PII processor generally acts on the documented instructions of the cloud customer (the PII controller), certain controller-facing principles - notably obtaining consent and defining the purpose of processing - remain the customer's responsibility, and the standard reflects this division of labour explicitly.
A crucial commercial commitment embedded in the standard is that the cloud provider must not use the PII it processes for its own purposes - in particular, not for advertising or marketing - without the explicit prior consent of the customer, and that such consent must never be a condition of receiving the service. This single provision is one of the most cited reasons enterprises demand ISO 27018 certification from their vendors.
Key definitions used throughout the standard
| Term | Meaning in ISO 27018 context |
|---|
| PII (personally identifiable information) | Any information that can identify a natural person, or be linked to them - equivalent to 'personal data' in GDPR / DPDP terminology. |
| PII principal | The natural person the PII relates to - the 'data subject' / 'data principal'. |
| PII controller | The entity that determines the purposes and means of processing PII - here, typically the cloud service customer. |
| PII processor | The entity that processes PII on behalf of, and per the instructions of, the PII controller - here, the public cloud provider seeking certification. |
| Public cloud PII processor | The specific role ISO 27018 governs: a provider processing customer PII in a multi-tenant public cloud. |
| Cloud service customer | The organisation that buys the cloud service and supplies (or whose users supply) the PII. |
| Processing | Any operation on PII: collection, storage, use, transfer, disclosure, retention, erasure, etc. |
Who must comply with ISO 27018
ISO 27018 is written for organisations that provide information-processing services as PII processors via a public cloud - across IaaS, PaaS and SaaS delivery models. It is voluntary in the sense that no law mandates it by name, but it becomes contractually mandatory whenever an enterprise customer, a public-sector tender, or a regulated-industry buyer requires it in their vendor due-diligence. In practice the demand comes from data-protection obligations flowing down the supply chain: a controller that must appoint only processors offering 'sufficient guarantees' (GDPR Article 28) uses ISO 27018 certification as objective evidence of those guarantees.
| Organisation type | Why ISO 27018 applies |
|---|
| Public SaaS providers (CRM, HR, marketing, analytics) | They store and process customer and end-user PII at scale as processors; certification is a competitive and procurement necessity. |
| IaaS / PaaS hyperscalers and regional cloud providers | They host customer workloads containing PII and must prove processor-side privacy controls and non-use of data. |
| Managed service and hosting providers | They operate infrastructure that holds customer PII and must demonstrate processor discipline. |
| BPO / KPO and outsourced processing firms using cloud | They process PII (payroll, claims, support) on client instruction in public-cloud environments. |
| Fintech, healthtech and edtech platforms | They handle sensitive PII and face both regulatory scrutiny and enterprise buyer demands. |
| Data centre operators offering multi-tenant services | They provide the physical and virtual layer in which customer PII resides. |
| Sub-processors in a cloud supply chain | They inherit processor obligations and are frequently required to be independently certified. |
Organisations acting purely as PII controllers (deciding purposes for their own data) are not the primary audience; for them ISO/IEC 27701 (the PIMS extension covering both controller and processor duties) is the broader fit. However, most cloud providers wear both hats and increasingly pursue ISO 27018 and ISO 27701 together on an ISO 27001 base.
Structure of ISO 27018
ISO 27018 is not a standalone control catalogue. Its normative body (clauses 5 to 18) mirrors the clause structure of ISO/IEC 27002, providing augmented guidance only where cloud-PII risk demands it, and its Annex A adds the genuinely new processor privacy controls organised by the eleven ISO/IEC 29100 privacy principles. Understanding this two-part structure is essential to scoping an assessment: you must check both the augmented 27002 controls and the additional Annex A controls.
| Part / clause area | Coverage and role |
|---|
| Clauses 1-4 | Scope, normative references, terms and definitions, and the overview/structure of the code of practice. |
| Clause 5 - Information security policies | Augmented guidance: policies must address the protection of PII and the processor role explicitly. |
| Clause 6 - Organisation of information security | Roles, responsibilities and segregation of duties applied to PII processing. |
| Clause 7 - Human resource security | Screening, confidentiality obligations and awareness specifically for staff who can access PII. |
| Clause 8 - Asset management | Handling and classification of media containing PII. |
| Clause 9 - Access control | User registration, privileged access and authentication hardened for PII environments. |
| Clause 10 - Cryptography | Encryption of PII in transit and at rest, and key management guidance. |
| Clause 11 - Physical and environmental security | Protection and secure disposal of media holding PII. |
| Clause 12 - Operations security | Logging, monitoring, malware protection and backup for PII processing systems. |
| Clause 13 - Communications security | Secure transfer of PII across and beyond the network. |
| Clause 16 - Information security incident management | Breach handling, including notification to the cloud customer. |
| Clause 18 - Compliance | Legal, regulatory and contractual compliance relating to PII. |
| Annex A - Public cloud PII processor extended control set | The 25 additional privacy controls (A.1-A.11) grouped by the eleven ISO/IEC 29100 principles - the heart of ISO 27018. |
Annex A groups its additional controls under the privacy-principle families listed below. These families, and the controls within them, are the master checklist that any ISO 27018 assessment must walk through in full.
| Annex A family | Privacy principle addressed |
|---|
| A.1 | Consent and choice |
| A.2 | Purpose legitimacy and specification |
| A.3 | Collection limitation |
| A.4 | Data minimization |
| A.5 | Use, retention and disclosure limitation |
| A.6 | Accuracy and quality |
| A.7 | Openness, transparency and notice |
| A.8 | Individual participation and access |
| A.9 | Accountability |
| A.10 | Information security |
| A.11 | Privacy compliance |
Master assessment checklist - every control area
This is the operative section of the guide. It enumerates each Annex A privacy-control family and the augmented ISO 27002 clause areas that ISO 27018 specifically strengthens. For each group, use the table to drive verification: confirm the control operates as intended and gather the typical evidence listed. Do not skip any family - certification requires demonstrable conformity across the entire set.
A.1 Consent and choice
| What to verify | Typical evidence |
|---|
| The provider does not use PII received for marketing/advertising unless the customer gives explicit prior consent, and never makes such consent a condition of service. | Acceptable-use and data-handling policy; contract clauses prohibiting secondary use; sign-off records for any customer marketing consent. |
| Any temporary files created during processing are erased/disposed of within a documented, bounded period. | Temp-file lifecycle procedure; automated cleanup job configuration and logs. |
A.2 Purpose legitimacy and specification
| What to verify | Typical evidence |
|---|
| PII is processed strictly per the documented instructions of the cloud customer, and instructions define the permitted purposes. | Data processing agreement (DPA); documented processing instructions; change-control for instruction updates. |
| Mechanisms exist to reject or flag any processing that would exceed the customer's stated purpose. | Exception-handling procedure; escalation records where instructions were unclear or unlawful. |
A.3 Collection limitation
| What to verify | Typical evidence |
|---|
| The provider does not collect PII beyond what the customer's processing instructions require. | Service design records; data-flow diagrams showing collection points limited to contracted purposes. |
| Controls prevent inadvertent over-collection through logging, telemetry or diagnostics. | Log-field review; telemetry configuration confirming PII minimisation in operational data. |
A.4 Data minimization
| What to verify | Typical evidence |
|---|
| PII is minimised in transient and derivative data - caches, temp stores, debug output, test data. | Data-minimisation standard; screenshots/config of masking in non-production; test-data management policy. |
| Secure deletion routines ensure PII is not retained in minimised form beyond need. | Deletion job schedules and logs; sanitisation records for decommissioned media. |
A.5 Use, retention and disclosure limitation
| What to verify | Typical evidence |
|---|
| PII is not disclosed to third parties except on the customer's instruction or where legally compelled. | Disclosure register; contractual sub-processor list; approval workflow for any disclosure. |
| Where law-enforcement or governmental disclosure is legally binding, the provider notifies the customer unless prohibited, and records each request. | Law-enforcement request log; legal-review records; customer-notification correspondence. |
| Retention periods for PII match the contract, after which secure erasure occurs. | Retention schedule; end-of-contract data-return/deletion certificates. |
| A record of PII disclosures to third parties is maintained. | Disclosure/transfer register with recipient, purpose, date and legal basis. |
A.6 Accuracy and quality
| What to verify | Typical evidence |
|---|
| Processing tools and configurations are set so PII is processed reliably and errors introduced by the processor are avoided. | Data-integrity controls; validation/checksum configuration; error-handling and reconciliation records. |
| The provider supports the customer's ability to keep PII accurate (e.g. facilitating corrections requested by principals via the customer). | Correction/rectification support procedure; ticket records of accuracy requests forwarded/actioned. |
A.7 Openness, transparency and notice
| What to verify | Typical evidence |
|---|
| The provider discloses the countries/geographies where PII may be stored or processed, and the existence of sub-processors. | Public sub-processor list; data-location/residency documentation; transparency page or contract schedule. |
| Customers are informed of any use of sub-contractors before PII is entrusted to them. | Sub-processor notification/consent records; change-notification communications. |
A.8 Individual participation and access
| What to verify | Typical evidence |
|---|
| The provider offers the customer the means to fulfil PII principals' rights (access, correction, erasure) - as processor support, not as controller. | Data-subject-request (DSR) support tooling/API; documented SLA for assisting the customer; DSR handling records. |
| Technical capability exists to locate, extract, correct and delete an individual's PII on request. | Export/erasure feature documentation; test evidence of an end-to-end DSR fulfilment. |
A.9 Accountability
| What to verify | Typical evidence |
|---|
| A PII breach is notified to the cloud customer within the timeframe and detail agreed, and a breach-response procedure exists. | Breach-notification procedure; customer-notification templates; incident log with timings. |
| Records of PII disclosures and processing decisions are retained for accountability. | Processing records; audit logs; retention evidence for accountability artefacts. |
| Where the provider proposes changes affecting the ability to comply, the customer is notified in time to object. | Change-management communications; customer objection/consent trail. |
A.10 Information security
| What to verify | Typical evidence |
|---|
| A confidentiality/non-disclosure obligation binds all staff and contractors with access to PII. | Signed confidentiality agreements; onboarding records; contractor NDAs. |
| Access to PII is on a need-to-know basis with unique identifiers and strong authentication; shared accounts are avoided. | IAM policy; access-review reports; MFA configuration; user-ID uniqueness evidence. |
| User access records are maintained, and privileged access to PII is restricted and monitored. | Privileged-access management logs; periodic access recertification; joiner/mover/leaver records. |
| PII transferred over networks is protected, and media containing PII is protected and securely disposed of. | Encryption-in-transit configuration (TLS); media-handling and sanitisation records; destruction certificates. |
| Encryption is applied to PII where appropriate, with sound key management. | Encryption-at-rest configuration; KMS/HSM records; key-rotation logs. |
| A policy restricts creation of hardcopy PII; where produced, it is controlled. | Print-control policy; secure-print and disposal records. |
| Data-restoration and backup procedures for PII are tested and effective. | Backup schedules; restoration-test reports; recovery-time evidence. |
| Failures to meet security obligations and detected/attempted access breaches are logged and reviewed. | Security event logs; SIEM alerts; incident-review minutes. |
| Portable media and devices that may hold PII are controlled, and unencrypted transfer to such media is restricted. | Removable-media policy; DLP configuration; device-encryption enforcement. |
A.11 Privacy compliance
| What to verify | Typical evidence |
|---|
| Geographic locations where PII may be processed are documented so the customer can assess legal compliance. | Data-residency register; processing-location schedule in the contract. |
| The intended destinations of PII and sub-processor jurisdictions are made available to the customer. | Cross-border transfer documentation; transfer-mechanism records (SCCs, adequacy, etc.). |
| Records are kept to demonstrate compliance and support customer and regulator audits. | Compliance evidence repository; audit reports; conformity records. |
Augmented ISO/IEC 27002 clause controls (5-18)
| What to verify | Typical evidence |
|---|
| Clause 5/6 - Policies and organisation address PII and the processor role explicitly, with defined privacy roles. | Information security & privacy policy set; RACI for PII; role appointment records. |
| Clause 7 - HR security includes screening, confidentiality terms and privacy awareness for PII-facing staff. | Screening records; training completion logs; disciplinary process. |
| Clause 8/11 - Asset/media handling and secure disposal cover PII-bearing media. | Asset inventory; media-sanitisation and destruction certificates. |
| Clause 9 - Access control enforces least privilege, unique IDs, MFA and periodic review for PII systems. | IAM configuration; access-review reports; authentication policy. |
| Clause 10 - Cryptography protects PII in transit and at rest with managed keys. | Crypto standard; TLS/encryption config; key-management records. |
| Clause 12/13 - Operations and communications security: logging, monitoring, malware protection, backup, secure transfer of PII. | Log configuration; SIEM dashboards; backup and transfer-security evidence. |
| Clause 16 - Incident management includes PII-breach detection, response and customer notification. | Incident-response plan; breach log; notification records. |
| Clause 18 - Compliance covers legal/regulatory/contractual obligations affecting PII, with periodic review. | Legal register; compliance review minutes; internal audit reports. |
Scoping the ISO 27018 assessment
Because ISO 27018 layers onto an ISO 27001 ISMS, scoping begins with the ISMS scope and then narrows to the public-cloud services that process customer PII. A precise scope statement prevents both under-coverage (missing a PII-processing service) and over-coverage (auditing infrastructure that never touches PII).
- Identify each public-cloud service (IaaS/PaaS/SaaS) offered where the organisation acts as a PII processor.
- Map the data flows: where PII enters, is stored, processed, transferred cross-border, backed up and deleted.
- Confirm the role boundary for each service - processor versus controller - since ISO 27018 governs the processor role.
- Enumerate sub-processors and the portions of processing they perform.
- Define geographic scope: all data-centre regions and jurisdictions where in-scope PII may reside.
- Include supporting functions: IAM, logging, backup, incident response, HR and physical security that underpin PII protection.
- Align the ISO 27018 scope statement with the ISO 27001 certificate scope, extending rather than contradicting it.
- Document exclusions with justification (e.g. services processing no PII, or where the organisation is solely a controller).
Implementation approach
ISO 27018 is best implemented as a phased extension of an existing or concurrent ISO 27001 programme. The following five phases carry an organisation from gap analysis to certification and continual improvement.
Phase 1 - Initiation and gap assessment
- Activities: secure management commitment; confirm the ISO 27001 base is in place or planned; define the processor scope; run a gap analysis against every augmented clause and all Annex A controls; identify sub-processors and data flows.
- Deliverables: ISO 27018 scope statement; gap-analysis report; data-flow and PII inventory; sub-processor register; project charter and RACI.
Phase 2 - Design and policy development
- Activities: draft or update policies for PII handling, consent/non-use, retention, disclosure, breach notification and sub-processor management; design DSR-support tooling and data-residency transparency; define the Statement of Applicability entries for ISO 27018 controls.
- Deliverables: PII-protection policy suite; updated Statement of Applicability; retention and deletion schedules; sub-processor management procedure; customer transparency artefacts (sub-processor list, data-location disclosures).
Phase 3 - Implementation and operationalisation
- Activities: deploy technical controls (encryption in transit/at rest, KMS, MFA, least-privilege IAM, DLP, logging/monitoring, secure deletion); implement DSR export/erasure capability; embed breach-notification workflow; roll out privacy awareness training; update contracts and DPAs.
- Deliverables: hardened cloud configurations; DSR tooling in production; breach-response runbook; training records; executed DPAs and confidentiality agreements.
Phase 4 - Internal audit and management review
- Activities: conduct an internal audit against the full ISO 27018 control set; test controls end-to-end (e.g. simulate a DSR and a breach notification); remediate nonconformities; run management review.
- Deliverables: internal audit report; corrective-action plan and closure evidence; management-review minutes; readiness assessment.
Phase 5 - Certification and continual improvement
- Activities: engage an accredited certification body for the combined ISO 27001 + ISO 27018 Stage 1 (documentation) and Stage 2 (implementation) audits; close findings; maintain via surveillance audits and ongoing monitoring.
- Deliverables: ISO 27001 certificate with ISO 27018 scope; Stage 1/2 audit reports; surveillance-audit programme; continual-improvement KPIs and metrics dashboard.
Maturity and capability model
ISO 27018 does not prescribe its own maturity scale, but organisations benefit from measuring capability to prioritise investment and track progress toward certification. A five-level model (aligned with common CMMI-style scales) works well for the privacy-control set.
| Level | Capability description |
|---|
| 1 - Initial | Privacy controls are ad hoc or absent; PII handling depends on individuals; no processor policies or DPAs in place. |
| 2 - Repeatable | Basic controls exist for major services but are inconsistent; some contracts address non-use and retention; DSR handling is manual and slow. |
| 3 - Defined | Documented policies, Annex A controls and Statement of Applicability cover all in-scope services; sub-processor and residency transparency established. |
| 4 - Managed | Controls are measured (breach-notification timeliness, DSR SLA, access-review coverage); internal audits confirm operation; metrics drive correction. |
| 5 - Optimising | Continual improvement embedded; automation of deletion, DSR fulfilment and monitoring; privacy-by-design in every new service; certification maintained without major findings. |
Assessment and audit approach
- Confirm the ISO 27001 ISMS foundation and define the ISO 27018 processor scope and boundaries.
- Review documentation (Stage 1): policies, Statement of Applicability, DPAs, sub-processor register, data-flow maps and residency disclosures.
- Plan the on-site/remote assessment (Stage 2), selecting samples across services, regions and control families.
- Walk through each Annex A family (A.1-A.11) and each augmented clause, testing design and operating effectiveness.
- Execute functional tests: simulate a data-subject request end-to-end and a PII-breach notification against the agreed timeframe.
- Inspect technical evidence: encryption, key management, IAM/MFA, logging, secure deletion, backup restoration.
- Verify third-party and sub-processor controls, contracts and transparency to customers.
- Record findings, grade nonconformities (major/minor) and observations, and agree corrective actions with owners and dates.
- Validate remediation evidence and, for certification, confirm closure before the certificate is issued.
- Establish the surveillance-audit cycle and continual-monitoring metrics for the certification lifetime.
Evidence request list
Assemble evidence by category ahead of any Stage 2 or surveillance audit. The lists below are indicative of what an auditor will request.
- Governance and policy: ISO 27001 certificate and scope; Statement of Applicability with ISO 27018 controls; PII-protection policy suite; acceptable-use and non-use (marketing) policy.
- Contracts and roles: data processing agreements; sub-processor contracts and register; confidentiality/NDA agreements; RACI for privacy roles.
- Data mapping: PII inventory; data-flow diagrams; data-residency/location register; cross-border transfer mechanisms.
- Access and security: IAM and MFA configuration; access-review and recertification reports; encryption-in-transit and at-rest configurations; key-management records; DLP and removable-media controls.
- Operations: logging and monitoring/SIEM evidence; malware protection; backup schedules and restoration-test reports; secure-deletion and media-sanitisation certificates.
- Individual rights: DSR-support tooling documentation; sample DSR fulfilment records (access, correction, erasure, export).
- Incident and breach: breach-notification procedure and templates; incident log with timings; sample customer notifications.
- Transparency: public sub-processor list; data-location disclosures; customer notification records for sub-processor or processing changes.
- Assurance: internal audit reports; corrective-action plans and closure; management-review minutes; training completion records; prior certification/surveillance reports.
Roles and responsibilities
| Role | Responsibility for ISO 27018 |
|---|
| Top management | Provides commitment, approves scope and policy, allocates resources, owns the management review. |
| Data Protection Officer / Privacy Lead | Owns the privacy-control programme, Annex A conformity, DSR and breach processes, and regulator liaison. |
| CISO / Information Security Manager | Owns the ISMS base, augmented ISO 27002 controls, encryption, IAM, logging and incident response. |
| Cloud service/product owners | Ensure each in-scope service implements privacy-by-design and operates the required controls. |
| Legal and contracts team | Maintains DPAs, sub-processor contracts, cross-border transfer mechanisms and law-enforcement request handling. |
| Vendor/sub-processor manager | Manages sub-processor due diligence, contracts, transparency and monitoring. |
| Internal audit | Independently assesses control operation and reports nonconformities. |
| HR | Delivers screening, confidentiality terms and privacy awareness training. |
| All staff/contractors with PII access | Comply with confidentiality, least-privilege and handling rules; report incidents promptly. |
KPIs to track
- Percentage of in-scope services with all Annex A controls implemented and evidenced.
- Mean time to notify the customer of a PII breach against the contractual SLA.
- Data-subject-request fulfilment time (access, correction, erasure) versus target SLA.
- Percentage of PII encrypted in transit and at rest across in-scope services.
- Access-review coverage and percentage of privileged accounts recertified on schedule.
- Number of processing activities operating strictly within documented customer instructions (exceptions flagged).
- Retention-schedule adherence: percentage of PII deleted within defined periods; overdue-deletion count.
- Sub-processor transparency currency: percentage of customers notified of sub-processor changes within the agreed window.
- Number and severity of audit nonconformities per cycle, and average time to close corrective actions.
- Privacy-awareness training completion rate for PII-facing staff.
- Backup-restoration test success rate for PII systems.
- Number of law-enforcement/government disclosure requests received, reviewed and (where permitted) notified to customers.
Readiness checklist
- ISO 27001 ISMS is certified or certification-ready and its scope covers the cloud PII-processing services.
- The ISO 27018 processor scope statement is documented and agreed.
- PII inventory and data-flow maps are complete, including cross-border and sub-processor flows.
- Statement of Applicability includes all applicable ISO 27018 augmented and Annex A controls with justifications.
- Policies cover non-use for marketing, consent, retention, disclosure, breach notification and sub-processor management.
- Data processing agreements and confidentiality/NDA agreements are executed with all relevant parties.
- Encryption in transit and at rest, key management, MFA and least-privilege IAM are implemented and evidenced.
- Secure-deletion, media-sanitisation and temp-file cleanup routines operate and are logged.
- DSR-support tooling can locate, export, correct and erase an individual's PII, tested end-to-end.
- Breach-notification workflow is defined, tested and meets the agreed customer timeframe.
- Sub-processor list and data-location disclosures are published and kept current.
- Logging, monitoring and backup-restoration testing are operational for PII systems.
- Privacy-awareness training is completed by all PII-facing staff.
- Internal audit and management review of the ISO 27018 controls are complete with corrective actions closed.
Common gaps
- Treating ISO 27018 as standalone and neglecting the underlying ISO 27001 ISMS it depends on.
- No explicit contractual commitment prohibiting use of customer PII for the provider's own marketing/advertising.
- Missing or stale sub-processor transparency - customers not notified of sub-processors or data locations.
- PII leaking into logs, telemetry, diagnostics, caches and non-production test data with no minimisation or masking.
- Manual, slow or unproven data-subject-request handling with no tested export/erasure capability.
- Breach-notification timeframes to customers undefined or untested against the contractual SLA.
- Retention and secure-deletion schedules absent, so PII persists in backups and temp stores beyond need.
- Weak key management - encryption enabled but keys poorly rotated, stored or access-controlled.
- Shared or generic administrative accounts on PII systems instead of unique IDs with MFA.
- No documented handling of law-enforcement/government disclosure requests and customer notification.
- Data-residency and cross-border transfer mechanisms undocumented, blocking customer legal assessment.
- Statement of Applicability that omits Annex A controls or lacks justification for exclusions.
ISO 27018 mapped to other frameworks
| Framework | Relationship to ISO 27018 |
|---|
| ISO/IEC 27001 | The mandatory ISMS foundation; ISO 27018 certification is issued as an extension of the 27001 certificate scope. |
| ISO/IEC 27002 | ISO 27018 augments a subset of 27002 controls with PII-specific implementation guidance. |
| ISO/IEC 27701 (PIMS) | Broader privacy extension covering both controller and processor duties; ISO 27018's processor controls align with and are subsumed by 27701's Annex B processor guidance. |
| ISO/IEC 29100 | Provides the eleven privacy principles that structure ISO 27018's Annex A families. |
| ISO/IEC 27017 | Companion cloud-security code of practice; often implemented alongside 27018 (security for cloud vs privacy for cloud PII). |
| EU GDPR | ISO 27018 supports Article 28 'sufficient guarantees' for processors and evidences processor-side accountability, security and transparency. |
| India DPDP Act 2023 | Supports Data Processor obligations (processing on controller instruction, security safeguards, breach handling) under the Act. |
| NIST Privacy Framework | Maps to the Control-P and Communicate-P functions; ISO 27018 controls support 'Govern', 'Control' and 'Protect' outcomes. |
| SOC 2 (Privacy & Confidentiality) | ISO 27018 evidence supports the Privacy and Confidentiality Trust Services Criteria in a SOC 2 report. |
How CyberSigma helps
CyberSigma runs end-to-end ISO/IEC 27018 engagements for public-cloud PII processors. We start with a gap assessment against every augmented ISO 27002 clause and all eleven Annex A privacy families, then build the processor policy suite, Statement of Applicability, DPAs and sub-processor transparency artefacts. Our engineers implement and validate the technical controls - encryption and key management, least-privilege IAM with MFA, secure deletion, DSR export/erasure tooling and breach-notification workflows - and we run internal audits and management reviews to close nonconformities before certification. Because we deliver ISO 27018 as an integrated extension of ISO 27001 (and, where useful, ISO 27017 and ISO 27701), you achieve certification faster and with a single, coherent evidence base that also satisfies GDPR, the DPDP Act and enterprise procurement due-diligence.
