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
Sections
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
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

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"
iso.org
Referenced sections
  • ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.
"Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors"
iso.org
Referenced sections
  • Primary ISO listing for the 2025 edition of ISO/IEC 27018.
"Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors"
Related guides

Explore more topics

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 Cloud Privacy FAQ
ISO/IEC 27018 FAQ on public-cloud PII processor scope, customer instructions, subprocessors, disclosures, breaches, deletion, audit evidence, and GDPR.
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 DPA Clause Review Workflow
Review cloud data-processing terms for instructions, purpose limits, controls, subprocessors, disclosures, incidents, rights support, and deletion.
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 Evidence Workflow
Triage a government request for customer PII, validate authority, decide notice and challenge options, minimize disclosure, and preserve the decision record.
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 Privacy Control Checklist
A practical ISO/IEC 27018:2025 checklist for public-cloud PII processors, with verifiable conditions, owners, evidence, exceptions, and edition controls.
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 Public Cloud PII Processor Scope Guide
Decide whether a service fits ISO/IEC 27018's public-cloud PII processor scope, separate processor and controller activities, and document the boundary.
ISO/IEC 27018 Subprocessor Evidence Guide
Build subprocessor evidence that proves who processed customer PII, where, under which terms and controls, after which notice and approval, and with what exit result.
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 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.
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.