DAT-023 Customer Data Export and Portability
Description
A customer can retrieve the data it holds in the service through a documented interface or API, in a structured, commonly used, machine-readable format. Import and export both run over current encrypted transport protocols. The documentation states the export scope, the format of each exported data type, the period after termination during which retrieval stays available and the point at which the data is deleted. An export produced through that interface is complete against the documented scope. The export documentation is a maintained register reachable by customers that names each data structure, the format each exported type is available in and the standard or open interoperability specification that format conforms to, updated when a format or a conformance claim changes. The documented scope covers the personal and non-personal input and output data that a customer's use of the service generates or cogenerates, metadata included, and each category held back from it is named with the ground for holding it back. The register names the arrangement through which the documented scope stays retrievable where the organisation is insolvent, in resolution or has discontinued the service, together with the date that arrangement was last verified.
Rationale
Export is what a customer relies on to leave, to satisfy its own regulator or to recover from a dispute, so the capability is tested against the documented scope rather than assumed from the existence of an API. Naming the post-termination window and the deletion point in the same place stops the two from drifting apart. DAT-011 holds the individual's portability right, DAT-008 the retention and deletion schedule behind the termination clock and VND-004 the contractual exit provisions. Issued in S4 from the NC-I proposal in docs/review-coverage-security.md section 2.1. A register differs from a migration guide in two ways an assessor can test: it is versioned against the service rather than written once, and a conformance claim in it names a specification rather than a file extension. The retrieval arrangement is here because the interface is the part of an export that stops working first, so an escrow, a customer-held copy or a standing replica answers a question a running API cannot. DAT-026 exercises the transition itself and DAT-027 governs who may reach the interface and on what terms; DAT-023 states what the export contains and where it is documented.
Applicability (9 profiles)
Export and portability are commitments of a hosted service to its tenants.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the export interface and the retrieval window belong to the service it operates. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the export interface and the post-termination retrieval terms are obtained under VND-004 and BCM-010 so the exit plan can be exercised.
Condition: deployment_model in cloud-saas, cloud-single-tenant
Export and portability are commitments of a hosted service to its tenants. Conditional since 1.1: the profile lists every deployment model and this row is a commitment of a hosted service, so a provider that publishes weights or runs on infrastructure the customer controls has no hosted service to carry it (ADR-046 amendment, 2026-09-16).
Export and portability are commitments of a hosted service to its tenants.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the export interface and the retrieval window belong to the service it operates. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the export interface and the post-termination retrieval terms are obtained under VND-004 and BCM-010 so the exit plan can be exercised.
EX-100 written in S8 wave B (migration 057). The export documentation is now a maintained register a customer can reach, naming each data structure, the format each exported type is available in and the standard or open interoperability specification that format conforms to, updated when a format or a conformance claim changes, and the documented scope is the personal and non-personal input and output data a customer's use generates or cogenerates, metadata included, with any held-back category named and grounded. Art. 26(b), Art. 30(4) and Art. 30(5) hold full. What the instrument still adds sits elsewhere: the retrieval period of at least 30 calendar days running from the end of the transitional period and the contract form on VND-013, and digital assets and the free-tier customer on DAT-027.
EX-90 written in S8 wave B (migration 057). The export register now names the arrangement through which the documented retrieval scope stays reachable where the organisation is insolvent, in resolution or has discontinued the service, with the date that arrangement was last verified, and the scope covers personal and non-personal data alike, so Art. 30(2)(d) holds full. DAT-026 exercises the transition itself and VND-013 carries the same commitment where the customer contract has to hold it as a term.
Export and portability are commitments of a hosted service to its tenants.
Export and portability are commitments of a hosted service to its tenants.
Framework Mappings (20)
| IPY-01 | Interoperability and Portability Policy and Procedures | partial |
| IPY-02 | Application Interface Availability | full |
| IPY-03 | Secure Interoperability and Portability Management | full |
| IPY-04 | Data Portability Contractual Obligations | partial |
| IPY-01 | Interoperability and Portability Policy and Procedures | partial |
| IPY-02 | Application Interface Availability | full |
| IPY-03 | Secure Interoperability and Portability Management | full |
| IPY-04 | Data Portability Contractual Obligations | partial |
| DORA-Art.28.8 | Exit strategies for ICT services supporting critical or important functions | informative |
| DORA-Art.30.2.d | Access, recovery and return of data on insolvency or termination | full |
| EU-DA-Art.23 | Removal of Switching Obstacles | partial |
| EU-DA-Art.23.c | Porting of Exportable Data and Digital Assets | partial |
| EU-DA-Art.25.2.a.iv | Security of Data During Transfer and Retrieval | partial |
| EU-DA-Art.25.2.e | Exhaustive Specification of Portable Data and Digital Assets | partial |
| EU-DA-Art.25.2.g | Minimum Thirty-Day Data Retrieval Period | partial |
| EU-DA-Art.25.2.h | Guaranteed Erasure After the Retrieval Period | informative |
| EU-DA-Art.26.a | Switching and Porting Procedure Information | partial |
| EU-DA-Art.26.b | Online Register of Data Structures and Formats | full |
| EU-DA-Art.30.4 | Register Update on Interoperability Compliance | full |
| EU-DA-Art.30.5 | Export of All Exportable Data on Request | full |
Evidence (2)
An export produced through the documented customer interface for a test tenant, with the request and response metadata showing the interface, the format and the transport used.
Example: Export bundle for tenant DEMO-EU produced through the v2 export API on 2026-08-20, with the request log showing the negotiated transport protocol and the manifest listing each included data type
Test: Produce an export through the documented interface for a tenant with data in every documented data type. Verify: (1) each documented data type appears in the export, (2) each is in the structured machine-readable format the documentation gives, (3) the transfer used a current encrypted transport protocol with no fallback to a deprecated version, (4) record counts in the export reconcile with the counts in the service for that tenant. (5) the export carries the input and output data the tenant's use generated or cogenerated, metadata included, and every documented type absent from it appears in the register as held back with its ground.
Published export and termination documentation stating the export scope, the format per data type, the retrieval window after termination and the deletion point. The documentation takes the form of a maintained register naming each data structure, the format of each exported type and the specification that format conforms to.
Example: Customer data export and offboarding guide v3.0, dated 2026-06-18, published in the product documentation and referenced from the master services agreement
Test: Read the export and termination documentation. Verify: (1) it names every customer data type the service holds and the format each is exported in, (2) it states the period after termination during which retrieval stays available, (3) it states when the data is deleted and how deletion is confirmed to the customer, (4) the stated window and deletion point agree with the retention schedule in DAT-008 and with the customer agreement. (5) the documentation is a register a customer can reach that names each data structure and the standard or open interoperability specification each format conforms to, carrying a version or date later than the most recent format change, (6) it names the arrangement that keeps the documented scope retrievable where the organisation is insolvent, in resolution or has discontinued the service, and the date that arrangement was last verified.
Questions (3)
Can a customer retrieve the data it holds in the service through a documented interface or API?
A support ticket that produces a manual database dump is not a documented interface. Answer yes where the customer can start and complete the retrieval itself against published documentation.
Which of the following does the export documentation state?
Count only what the published documentation states. The termination window and the deletion point are the two a customer needs before it signs and the two most often missing. A conformance claim counts where it names a specification a second system could be built against, not where it names a file type. The last item is the one an export API cannot answer for itself: insolvency, resolution and discontinuation all remove the interface the other items describe.
In what form is customer data exported?
Options run from strongest to weakest. Commonly used means a format another system can read without bespoke work, such as CSV, JSON or a documented archive of those. A PDF of the same content is not portable.