Core

A16. Privacy and legal mapping

Status: normative. Document version 1.0-draft-1.

A16.1 What the protocol supports

This subsection is informative. Protocol mechanisms can support privacy obligations; they do not establish lawful processing, legal compliance or certification. Roles, purposes, jurisdiction, safeguards and actual operation matter. A16.2 to A16.8 define deployment requirements for providers and recipients claiming conformance. They add no wire fields and do not turn conformance into legal approval.

The EU GDPR provisions most directly relevant include Articles 7, 9, 15, 16, 17, 20 and 25. Read their conditions and exceptions in the official regulation. UK applicability must be evaluated separately using current legislation and ICO consent guidance; it is not assumed identical to EU rules.

The EU Data Governance Act has its own scope, notification requirements and conditions, including Articles 11 and 12. A technical registry badge cannot confer data-intermediation status. Advertising eligibility rules in A6.7 are protocol restrictions, not a declaration that an advertising use is lawful.

The international privacy guide gives dated, informative jurisdiction notes and primary sources. It is not a substitute for the deployment assessment below and is not incorporated as normative law.

A16.2 Applicability, roles and lawful processing

Before collecting, storing, accepting a contribution, deriving or disclosing personal data, each deploying provider and recipient MUST document the applicable jurisdictions, its actual legal roles, purposes, data categories and lawful conditions for those operations. The assessment MUST consider the people served, establishment, targeting, sector and actual processing, rather than relying solely on nationality, IP address or hosting location. Where a required condition is absent or unresolved, the affected operation MUST remain disabled. Independently lawful operations need not be disabled.

Protocol actors do not determine legal roles. The assessment MUST distinguish independent, joint and processor relationships where applicable, including account administration, security logs, hosting and recipient use. Encryption and a person's household use do not automatically exempt a commercial provider. Required notices, agreements and evidence of the selected lawful conditions MUST be in place before the relevant processing.

A grant is a technical permission, not itself a lawful basis. Where consent is relied on, the implementation MUST retain proportionate evidence of the actual notice and version, language, purposes, parties, categories, affirmative action, time and withdrawal route. It MUST satisfy any applicable explicit, separate, written or representative-consent formality and permit refusal and withdrawal without prohibited detriment. Withdrawal MUST be as easy as giving consent where the law requires it. Grant acceptance MUST NOT waive statutory rights or authorise a purpose that the protocol prohibits.

Required indirect-collection notices MUST be handled at the legally required time. Data in a pending or rejected contribution has already been collected; a confirmation queue is not an exemption. Compliance records MUST remain protected and MUST NOT expand discovery or disclose additional personal data to recipients.

Check: PRIVACY-01.

A16.3 Sensitive data, necessity and further use

The provider and recipient MUST assess legal sensitivity for the actual data, source, inference and combination in each applicable jurisdiction. Vocabulary flags and disclosure levels are technical controls, not an exhaustive legal classification. A low-resolution rendering can remain personal or sensitive data. Implementations MUST NOT relabel data, lower its disclosure level or describe it as a preference to evade a legal restriction.

Collection, storage and disclosure MUST be limited to the purpose and necessity permitted by applicable law. Operations governed by a grant MUST also remain within that grant’s purpose and authority. Where processing requires a special condition, that condition MUST be established before the affected data is accepted or used. Consent MUST NOT be treated as overriding a statutory prohibition or strict necessity requirement. Unsupported categories and uses MUST remain disabled for the affected deployment.

Model training, advertising, enrichment and other further uses MUST NOT be inferred from permission to read, contribute or host a record. Any further use MUST satisfy its own applicable legal conditions and the protocol's purpose and authority limits; fresh consent cannot override a protocol prohibition.

Check: PRIVACY-02.

A16.4 International flows

Before an international flow begins, the deploying parties MUST document its source, destination, parties, purposes and data categories, including hosting, backups, remote access, subprocessors and onward disclosure. They MUST establish any required transfer mechanism, assessment, contract, notice, separate permission, filing, representation or localisation arrangement for that flow. A grant, encrypted transport, chosen hosting region or an agreement designed for another jurisdiction is not sufficient evidence by itself.

The assessment MUST record which flows an instrument covers, applicable conditions and a review point. A material change of destination, recipient, access arrangement or legal protection MUST trigger reassessment before the changed flow proceeds. A flow whose required safeguards are no longer satisfied MUST be suspended without silently selecting a different destination.

Check: PRIVACY-03.

A16.5 Rights, retention and erasure

Each deploying party MUST provide an accessible route for applicable access, correction, deletion, restriction, objection and portability requests, authorised representatives, complaints and appeals. Identity verification MUST be proportionate. It MUST NOT require a new account where applicable law prohibits doing so. The party MUST track the applicable deadline, any permitted extension, outcome, reasons and challenge route. A protocol export or read log alone MUST NOT be represented as a complete statutory response.

Correction MUST stop superseded information from being presented as current and communicate corrections or restrictions to recipients where required. Keeping both versions is not sufficient. Disputed or restricted data MUST be prevented from entering uses that the restriction prohibits.

Retention rules MUST cover entries, history, contributions, receipts, logs, caches, exports and backups. Grant expiry and revocation MUST NOT be treated as deletion. Append-only audit design MUST NOT imply indefinite personal-data retention. Implementations MUST use bounded history and proportionate evidence, with a tested deletion or effective cryptographic-erasure process where appropriate. Restoring a backup MUST reapply deletions and restrictions before restored data becomes available for processing.

Revocation, consent withdrawal, restriction and erasure MUST be handled as distinct actions with their actual effects explained. A10's default seven-day acknowledgement period is a protocol target, not a universal legal deadline. A recipient's purge acknowledgement MUST be described as its assertion, not proof that every copy has disappeared. Missing acknowledgements and incomplete deletion MUST have a tracked follow-up process.

Any retained data under a legal exception or hold MUST have a specific documented ground, restricted access and use, a review or end condition, and any legally required explanation and challenge route. Such retention MUST NOT be reported as erasure or become an implicit new grant.

Check: PRIVACY-04.

A16.6 Advertising choices and children

A6.7's advertising restrictions are an upper bound, not legal authorisation. Before enabling that optional capability, the deploying parties MUST assess whether the arrangement constitutes regulated sale, sharing, targeted advertising or another restricted use, including non-monetary consideration. The capability MUST remain disabled wherever a required condition cannot be met.

Implementations MUST honour applicable objections, opt-outs and recognised preference signals, including signals received after a grant was issued, before the next affected disclosure or use. A grant MUST NOT silently override a valid opt-out. The absence of a signal is not consent. Any legally permitted later opt-in MUST be handled through the required informed process. Version 1 defines no universal transport for these signals; an implementation without a reliable way to receive and enforce applicable choices MUST keep the affected advertising use disabled. Device access, cookies and direct marketing require their own assessment.

Version 1's reserved guardian mechanisms do not establish a child-consent or capacity framework. A deployment directed to children, or otherwise within applicable child-protection duties, MUST establish the required age, capacity, representative authority and child-specific safeguards through a separately specified and verified process before enabling affected processing. Until that process exists, the deployment MUST restrict its supported audience and affected functions accordingly, using proportionate measures. It MUST NOT claim that a generic checkbox establishes parental authority. Child and guardian advertising remains excluded by A6.7.

Check: PRIVACY-05.

A16.7 Accountability and regulated services

Each deploying party MUST establish the impact assessments, security measures, contracts, records, registrations, permits, licences, prior authorisations, officers and representatives required for its actual activity. Where an approval is required before processing or a transfer, the party MUST establish that it has been granted and covers the intended activity, rather than treating an application or personal consent as approval. It MUST track conditions, expiry and renewal, and stop the affected operation when required permission is absent or expires. It MUST maintain and exercise an incident process with jurisdiction-specific triggers, reporting routes and deadlines. Unauthorised disclosures, including misuse by an authorised recipient, MUST be assessed; incident handling MUST NOT assume that every law uses the same threshold or a 72-hour deadline.

A recipient using data for a decision subject to explanation, objection, review or human-intervention rights MUST provide the applicable process and information. A read receipt explains an access event, not the reasoning or consequences of a subsequent decision.

Parties MUST assess any activity-specific regime, including data intermediation, registered consent-management services and sector health or financial rules, before claiming that status. A technical provider, consent screen or registry entry MUST NOT be described as a legally registered or certified service without the required legal conditions, registration and any structural safeguards.

Check: PRIVACY-06.

A16.8 Evidence and claims

A deployment claiming conformance MUST hold evidence for PRIVACY-01 to PRIVACY-06 identifying the tested build, jurisdictions, supported uses and categories, assessment date, responsible reviewer, restrictions, operational procedures and observed results. Evidence MUST include representative exercises of the relevant consent, rights, transfer, retention, opt-out and incident processes. Legal applicability decisions require accountable review; automated schema checks cannot make them.

The deployment MUST reassess material changes in law, purpose, audience, data or flows. Public claims MUST state their scope and limitations without publishing personal data, privileged advice or confidential security details. A checklist, pending test or published contract MUST NOT be presented as an operating safeguard. No conformance statement under A17 may be labelled a legal compliance certificate.

Checks: PRIVACY-01 to PRIVACY-06 and CLAIM-01.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.