What does control A.2.5.6 require?
The organization shall reject any requests for PII disclosures that are not legally binding, consult the corresponding customer before making any PII disclosures and accept any contractually agreed requests for PII disclosures that are authorized by the corresponding customer.
This control sits within the PII Processor controls annex (A.2) and establishes a clear decision framework for handling PII disclosure requests. It creates a hierarchy: reject requests that lack legal force, consult the controller before disclosing and honour contractually agreed disclosures that the customer has authorised. This prevents processors from disclosing PII without proper authority.
What does the Annex B implementation guidance say?
Annex B (section B.2.5.6) provides the following guidance:
- Contractual details — Details of how disclosure requests are handled can be included in the customer contract
- Sources of requests — Disclosure requests can originate from courts, tribunals, administrative authorities or any other body with jurisdictional authority
- See also A.2.5.3: Countries and International Organizations for PII Transfer for related requirements
- See also A.2.5.7: Disclosure of Subcontractors Used to Process PII for related requirements
The guidance is deliberately concise because the control itself is highly prescriptive. The three-part obligation is clear: reject non-binding requests, consult the customer on binding requests and accept customer-authorised requests. The contract should define the procedures for each scenario, including how the processor determines whether a request is legally binding, how customer consultation takes place and what pre-authorised disclosures the customer has agreed to.
How does this map to GDPR?
Control A.2.5.6 maps to the following GDPR article:
- Article 48 — Any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognised or enforceable if based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting third country and the Union or a Member State
GDPR Article 48 is particularly relevant for processors operating internationally. It establishes that foreign court orders and administrative decisions cannot, by themselves, compel disclosure of personal data unless there is an international agreement in place. This reinforces the processor’s obligation to reject non-binding requests and to verify the legal basis before disclosure.
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was addressed within the broader clause structure. The 2025 edition provides A.2.5.6 as a standalone control with implementation guidance in B.2.5.6 that clarifies the sources of disclosure requests (courts, tribunals, administrative authorities) and the role of the customer contract. See the Annex F correspondence table for the full mapping.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
What evidence do auditors expect?
When assessing compliance with A.2.5.6, auditors will typically look for:
- Disclosure decision procedure — A documented procedure for evaluating disclosure requests, including how the organisation determines whether a request is legally binding
- Rejection records — Records of non-binding disclosure requests that were rejected, including the basis for the rejection and any correspondence with the requesting party
- Customer consultation records — Evidence of customer consultation before disclosures were made, including the communication, the customer’s response and the decision taken
- Pre-authorised disclosures — Contract clauses defining disclosures that the customer has pre-authorised, removing the need for case by case consultation
- Legal assessment capability — Evidence that the organisation has access to legal advice for assessing whether requests are legally binding, particularly for requests from foreign jurisdictions
What are the related controls?
| Control | Relationship |
|---|---|
| A.2.5.5 Notification of disclosure requests | Notification is the first step; this control governs the decision to disclose or reject |
| A.2.5.4 Records of PII disclosures | All disclosures (and rejections) should be recorded |
| A.2.2.2 Customer agreement | The contract defines the disclosure decision procedure and pre-authorised disclosures |
| A.2.5.2 Basis for PII transfer | Legally compelled disclosures to foreign authorities must have a valid transfer basis |
| A.2.2.4 Marketing and advertising use | Disclosures for marketing purposes require specific customer authorisation |
Who does this control apply to?
A.2.5.6 applies exclusively to PII processors. Processors act on behalf of controllers and should not independently decide to disclose PII to third parties. This control ensures that processors only disclose PII when there is either a legally binding obligation to do so or explicit customer authorisation. Voluntary disclosures without customer consent or legal compulsion are not permitted.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Why choose ISMS.online for disclosure decision management?
ISMS.online provides practical tools for managing PII disclosure decisions:
- Decision workflows — Structured workflows for evaluating disclosure requests, with branching logic for legally binding, non-binding and customer-authorised requests
- Legal assessment tracking — Record legal assessments of whether requests are binding, including the jurisdiction, legal provision cited and legal advice obtained
- Customer consultation — Manage customer consultations within the platform, tracking the request, communication, response and final decision
- Rejection management — Document rejected requests with the basis for rejection, creating a defensible record for regulatory or legal review
- Contract integration — Link disclosure procedures to customer contract provisions, ensuring pre-authorised disclosures are identified and handled consistently
FAQs
How does the processor determine if a request is legally binding?
The processor should assess whether the requesting authority has the legal power to compel disclosure and whether the request has been properly issued under the applicable law. This typically requires legal advice, particularly for requests from foreign jurisdictions. Key factors include: whether the request cites a specific legal provision; whether it has been issued by a court, tribunal or administrative authority with proper jurisdiction; and whether it meets the formal requirements of the applicable law. Informal requests, voluntary cooperation requests and requests that lack legal basis should be rejected.
Can the processor disclose PII without consulting the customer?
Only in limited circumstances. If the customer contract includes pre-authorised disclosures (for example, authorising disclosure in response to valid court orders within a specified jurisdiction), the processor can proceed without case by case consultation. Additionally, if notification is legally prohibited (as addressed in A.2.5.5 PII Disclosure Requests), the processor may need to disclose before being able to notify the customer. In all other cases, customer consultation before disclosure is required by this control.
What about requests from foreign courts or authorities?
GDPR Article 48 establishes that foreign court judgments and administrative decisions are only enforceable if based on an international agreement such as a mutual legal assistance treaty. This means that a foreign court order alone is not necessarily a “legally binding” request under EU law. The processor should obtain legal advice before disclosing PII in response to foreign authority requests and should consult the customer. Where no international agreement exists, the request should generally be rejected unless other GDPR transfer mechanisms apply.
