GuideGlobalISO/IEC 27018

ISO/IEC 27018 Government Access Evidence

Build a controlled record for legally compelled PII disclosures that supports customer assurance without exposing protected request details or other customers' data.

This page uses disclosure controls from withdrawn ISO/IEC 27018:2019. It cannot determine whether a request is binding or whether notice is lawful in a specific case. Check ISO/IEC 27018:2025, the contract, and the governing law with qualified counsel.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Overview

Government-access evidence should prove that the provider authenticated the request, obtained a legal decision, applied any challenge or narrowing route, decided whether customer notice was permitted, limited each to authorized data and a verified recipient, and closed the case. Aggregate transparency statistics cannot replace that case-level record.

Section 1

What must a government-access case record establish?

A case record must connect the original request to the requesting body, authentication check, cited authority, jurisdiction, service of process, deadline, affected provider entity, customer, service, account, period, requested PII, preservation instruction, legal reviewer, and final decision.

Record whether the demand was unauthenticated, invalid, voluntary, binding as issued, narrowed, challenged, withdrawn, prohibited from customer notice, or satisfied. Keep the reasoning and approval at the level permitted by privilege, secrecy, and internal access rules; a request label alone does not establish legal effect.

For any disclosure, reconcile the approved scope with the collected dataset and transfer record. Record excluded, unavailable, and withheld items so reviewers do not mistake the request's scope for what was actually disclosed.

Use separate fields for preservation, collection, disclosure, and notice. An obligation to preserve does not itself authorize disclosure, and authority to disclose does not always permit customer notice.

  • Request evidence: original demand and transmission metadata, service record, authentication check, cited legal instrument, deadline, and preservation terms.
  • Decision evidence: jurisdiction and authority analysis, scope review, challenge or narrowing steps, conflicts, notice decision, approvals, and customer-authorized instructions.
  • Disclosure evidence: approved query or collection specification, collector and reviewer, exact data inventory, integrity check where used, recipient and destination verification, channel, time, and receipt.
  • Closure evidence: customer communication where permitted, hold status, working-copy disposal, access-log review, error or incident record, lessons learned, and final sign-off.
Section 2

Which request, authority, notice, and disclosure records belong together?

ISO/IEC 27018:2019 calls for contractual notice of a legally binding law-enforcement request under the agreed procedure and timing unless disclosure is prohibited. Its guidance says the provider should reject non-binding requests and consult the customer before disclosure where legally permissible.

says third-party disclosures should record what PII was disclosed, to whom, and when; its guidance adds the source of the disclosure and source of authority. Keep those fields with the authentication, legal decision, notice outcome, approval, transfer, and closure records.

  • Request source: the demand and the verified identity of the issuing body.
  • Authority source: the legal instrument, order, warrant, summons, statute, customer authorization, or other basis accepted by the qualified reviewer.
  • Notice record: permitted, delayed, prohibited, or not applicable; recipient, content, channel, time, legal basis, reviewer, and reconsideration trigger.
  • Disclosure record: PII fields, accounts and dates, recipient, delivery time, authority, collector, reviewer, transfer method, and confirmation.
Section 3

How should access to sensitive case evidence be controlled?

Classify and separate request content, legal analysis, customer PII, disclosure exports, transfer records, and assurance summaries. Give access only to named roles with a case need, log access, protect exports in transit and at rest, and apply the case retention and legal-hold rules.

Customer assurance should show that the control operated without exposing another customer's PII, privileged analysis, sealed material, investigative details, or data whose disclosure is prohibited. Use a redacted case summary, sampled metadata, control walkthrough, or aggregate report when authorized.

  • Legal case file: full request, legal analysis, challenge and notice decisions, approvals, and protected communications.
  • Technical collection file: approved scope, query, collected items, reviewer, integrity data where used, transfer, and working-copy disposition.
  • Assurance file: case identifier, dates, process steps completed, authorized exceptions, and closure evidence with protected content removed.
  • Access review: current authorized users, access events, attempted unauthorized access, and removal after closure.
Section 4

Which government-access evidence gaps should be avoided?

Do not retain only the request and response letter. Without authentication, legal analysis, approved scope, exact disclosed-data inventory, destination check, and transfer record, the provider cannot show what decision it made or what it sent.

Do not treat a transparency report, policy, or ISO certificate as case evidence. Do not store protected legal material in an unrestricted audit folder. Do not leave a temporary notice prohibition or legal hold open without an owner and review trigger.

  • Missing authority source: reopen legal review before disclosure.
  • Request and customer mismatch: stop collection and confirm the correct account and provider entity.
  • Approved and delivered scope mismatch: treat over-disclosure or wrong-recipient delivery under the incident process and preserve the evidence.
  • Missing notice review: obtain a current legal decision; do not assume silence means notice is prohibited.
Section 5

When should the disclosure process and contract be reviewed?

Review each case after closure. Reconcile the request, decision, collection, disclosure, recipient confirmation, notice, holds, working copies, access logs, and final sign-off. Convert errors and near misses into owned corrective actions.

Review the procedure when laws, request portals, authorized recipients, provider entities, customer terms, processing locations, subprocessors, collection tooling, transfer channels, retention rules, or the cited ISO/IEC 27018 edition changes.

  • Test periodically with a scenario that covers authentication, legal escalation, narrowing, notice prohibition, controlled collection, second-person review, secure transfer, and closure.
  • Keep metrics separate from case proof: request counts and response times can reveal trends but cannot establish that a specific disclosure was authorized and limited.
  • Retain case evidence for the period set by applicable law, contract, privilege, investigation needs, and the documented retention policy; ISO/IEC 27018:2019 does not create one universal legal retention period.
Primary sources

References and citations

iso.org3 citations
Referenced sections
  • ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.
  • ISO/IEC 27018:2019 Annex A.6.1 and A.6.2 are the historical criteria for customer notification, rejection of non-binding requests, consultation where permissible, and disclosure records.
  • ISO/IEC 27018:2019 Annex A.6.2 and A.11 controls are the historical criteria used here for disclosure records and protection of PII and related logs.
"Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors"
iso.org2 citations
Referenced sections
  • Primary ISO listing for the 2025 edition of ISO/IEC 27018.
  • ISO identifies ISO/IEC 27018:2025 as the current edition for public-cloud providers acting as PII processors.
"Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors"
eur-lex.europa.eu
Referenced sections
  • Binding EU data protection regulation used for ISO/IEC 27018 comparison.
"protection of natural persons with regard to the processing of personal data"
Show all related guides (20)

ISO/IEC 27018 Subprocessor Evidence Workflow

Assess and approve a cloud subprocessor, disclose its use and countries before processing, handle customer objections, and retain operating and exit evidence.

ISO/IEC 27018 Vendor Contract Requirements Guide

Contract guide for ISO/IEC 27018 public-cloud PII processing: scope, instructions, security, subprocessors, disclosures, incidents, rights support, audits, and exit.

ISO/IEC 27018 vs GDPR Comparison

Compare ISO/IEC 27018 cloud-processor guidance with GDPR legal duties, including scope, Article 28 contracts, breaches, transfers, evidence, and assurance limits.

ISO/IEC 27018 vs ISO/IEC 27701 Comparison

Compare ISO/IEC 27018:2025 cloud-processor guidance with the independent ISO/IEC 27701:2025 privacy management system, including scope, evidence, and assurance.

ISO/IEC 27018 vs SOC 2 Privacy Comparison

Compare ISO/IEC 27018 cloud-processor guidance with a SOC 2 examination that includes Privacy, including scope, Type 1 vs Type 2, evidence, and limits.

Using ISO/IEC 27018 for Public-Cloud PII Processing

Decide whether ISO/IEC 27018:2025 applies to a public-cloud PII processor, how it fits an ISMS, what evidence to keep, and which claims the evidence supports.

ISO/IEC 27018 Audit Evidence FAQ

How to assess ISO/IEC 27018 audit evidence by edition, service scope, criteria, audit period, exceptions, and independent assurance.

ISO/IEC 27018 Breach Support FAQ

ISO/IEC 27018 breach support: when a cloud PII processor should notify a customer, what the contract should define, and what incident records to keep.

ISO/IEC 27018 Customer Instructions FAQ

What counts as a customer instruction under ISO/IEC 27018, how a cloud PII processor should validate it, and what evidence shows it was followed.

ISO/IEC 27018 GDPR Overlap FAQ

How ISO/IEC 27018 can support GDPR processor controls without replacing Article 28 terms, controller accountability, transfers, or breach duties.

ISO/IEC 27018 Government Access FAQ

How ISO/IEC 27018 addresses legally binding law-enforcement requests: validation, customer consultation or notice, limited disclosure, and records.

ISO/IEC 27018 PII Return and Deletion FAQ

How to plan and prove PII return, transfer, deletion, anonymization, or archival across live systems, backups, temporary files, and subprocessors.

ISO/IEC 27018 Processor Duties FAQ

What ISO/IEC 27018 expects from a public-cloud PII processor: customer instructions, purpose limits, security, transparency, incident support, and disposal.

ISO/IEC 27018 Subprocessor Notice FAQ

What an ISO/IEC 27018 subprocessor notice should disclose, when customers should receive it, and what evidence should support consent and objections.