ISO 27018 Vendor Assessment: Testing Cloud PII Claims

Follow the paper. Request the ISO 27001 certificate itself (not the trust-page summary) and read three things: whether the scope statement references ISO/IEC 27018, whether the legal entities and services named cover what you are buying (certificates routinely cover one platform, one region set, or one subsidiary), and the validity dates. Verify the certification body's accreditation in the relevant accreditation-body registry (ANAB, UKAS, DAkkS and peers); certificates from unaccredited bodies exist and are worth little. Then ask for the statement of applicability excerpt showing the 27018 annex controls selected, since a provider can reference the standard's guidance layer without adopting the annex commitments that matter. Where the provider offers a SOC 2 report or independent 27018 assessment instead, read the mapped criteria and exceptions rather than accepting the cover page. Calibrate effort to risk: for a hyperscaler, published audit reports and certificates through their compliance portals usually suffice; for a mid-market SaaS vendor processing your customer PII, the full paper chase is proportionate, and the vendors who handle it smoothly are self-selecting for real programs.

Six, each with a concrete test. Instructions-only processing: does the DPA define processing scope by customer instruction and prohibit processing beyond it, and does the product actually offer configuration reflecting this (data residency choices, feature-level toggles)? No advertising or marketing use: is the prohibition unconditional in the contract, or does a privacy policy carve-out for 'service improvement' or 'personalization' swallow it, read the provider's own privacy notice against the DPA, and treat conflicts as the answer. Subprocessor transparency: request the current list with processing locations, subscribe to the change-notification mechanism, and check the DPA gives objection rights with a real remedy (termination without penalty for the affected service). Customer-assistance machinery: how do DSAR-supporting exports, corrections, and deletions actually work, API, ticket, self-service, and at what latency; ask for the documentation, not assurances. Deletion: termination timelines, backup propagation windows, and deletion certification; 'deleted from production immediately, backups within N days' with N stated is the real answer, and vagueness here predicts pain. Breach notification: contractual commitment to notify 'without undue delay' with a defined outer bound (24-72 hours is market), covering unauthorized access to PII specifically, with named contact channels. Providers passing all six on paper and in product documentation are rare enough that the test itself ranks your vendor book.

Article 28(1) puts the selection duty on you: controllers may use only processors providing sufficient guarantees to implement appropriate technical and organizational measures. The 27018 assessment operationalizes 'sufficient guarantees' for cloud processors: the verified certificate and SoA evidence the technical-measure claims; the annex-commitment tests verify the processor-behavior claims (instructions, subprocessors, assistance, deletion, notification) that Article 28(3) requires as contract terms anyway. Practical integration: fold the assessment into your vendor-onboarding workflow so its outputs populate the DPA negotiation checklist, each verified commitment becomes a contract exhibit reference, each gap becomes a negotiation point or a compensating control; file the assessment record (what was checked, when, evidence retained) in the vendor register, because when a processor incident triggers a DPA inquiry, your documented diligence is the difference between the processor's violation and your violation too. Reassessment cadence: annually for high-risk processors and on certificate renewal, subprocessor-list changes affecting jurisdictions, or material product changes. And remember scope: 27018 diligence covers processor behavior; your own transfer analysis (where the data goes) and security assessment (whether measures fit your data's risk) remain separate columns in the same vendor file.

Ranked by severity. Contract-trust divergence: the trust page advertises 27018 but the DPA lacks the annex commitments, or contains advertising/profiling carve-outs; the contract is what binds, so this is a substantive failure dressed as an oversight, and how the vendor responds to redlines tells you whether the program is real. Scope evasion: certificates covering a different entity, platform, or region than the services sold, common after acquisitions, where the acquired product never entered the acquirer's certification scope. Subprocessor opacity: no published list, no change notification, or 'we use various service providers' language; under both 27018 and Article 28 this is disqualifying for meaningful PII processing. Deletion vagueness: refusal to state backup-propagation windows or provide deletion confirmation; if they cannot describe it, it is not implemented. Evidence refusal: unwillingness to share certificates, SoA excerpts, or assessment summaries under NDA, distinguishing this from reasonable confidentiality (full audit reports under NDA is normal; nothing at all is not). Softer signals worth noting: certificates from obscure unaccredited bodies, trust pages with badges but no documents, and DPAs that predate the claimed certification by years. Any single red flag is a negotiation item; two or more in the same vendor is a pattern, and patterns in privacy diligence are usually accurate.

As overlapping evidence with different centers of gravity, and take what each does best. 27018 (in a 27001 scope): the sharpest instrument for cloud-processor behavior, its annex asks exactly the questions a PII controller should ask a public cloud vendor, but it is guidance folded into a security certification, so depth of audit varies with the certification body. 27701: the strongest signal of a managed privacy program, processor controls plus the management-system spine (risk, audit, review), and its certificate stands alone; a vendor holding 27701 with processor scope typically clears the 27018 substance too, and the annex-mapping between them is published in the standard. SOC 2 Type II: the most detailed operational evidence, tested controls with exceptions over a real observation period, but privacy inclusion is rare, and a security-only SOC 2 says nothing about PII-processor behavior. Assessment algorithm: accept any of the three as the evidence spine, then test the six annex commitments regardless of which artifact arrived, because contract mirroring is the universal weak point; weight recency and scope over logo count; and for vendors holding none of the three, the six commitments become your bespoke questionnaire, with the DPA carrying the full evidentiary load. What you should not do is maintain three separate assessment tracks, one vendor file, one commitment checklist, artifacts slotted as evidence.