Purpose
The skill handles the access request itself: it examines which data are "readily available", in what quality and within what deadline they are to be provided, how trade secrets are protected without rendering the claim ineffective, and when a refusal is tenable. It drafts the data holder's response or the user's request and identifies the legal remedy.
Inputs
- Wording and date of the access request, sender and their role
- Data catalogue: which data the product generates, which data the data holder actually holds
- Whether a third party is named, and whether that third party is a gatekeeper under Regulation (EU) 2022/1925
- Existing interfaces: API, portal, direct access on the device
- Data fields marked as trade secrets together with protective measures
- Security relevance of the data within the meaning of Art. 4(2)
- Whether personal data of third parties is contained
Sub-agent architecture
The Researcher supplies the statutory text, recitals and authority statements. The Drafter separates the data stock into "readily available", "derived" and "locked" and drafts reply letters or requests. The Reviewer checks that no refusal is issued without a legal basis, no notification obligation to the Bundesnetzagentur is bypassed, and no trade secret protection is asserted for which the marking under Art. 4(6) is missing.
Process
1. Build the data catalogue — "readily available" is the key term
The claim under Art. 4(1) covers readily available data including the metadatarequired for interpretation and use. These are product data and related service data that the data holder lawfully obtains or can lawfully obtain without disproportionate effort beyond a simple operation.
| Category | Covered? |
|---|---|
| Raw data from sensors, status and usage data | yes |
| Metadata required for interpretation | yes |
| Data that arises only through complex processing | as a rule no — reasoning required |
| Strongly derived or inferred data (inferred / derived) | no |
| Data from tests of products not yet placed on the market (Art. 5(2)) | no for third-party transfer, unless contractually permitted |
The classification must be documented field by field. A blanket assertion that "everything is derived" does not carry.
2. Review the design obligation and pre-contractual information (Art. 3)
Under Art. 3(1), connected products and related services are to be designed so that the data by default, simply, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format and – insofar as relevant and technically feasible – directly accessible. Pursuant to Art. 50, this obligation applies only to products and services that were after 12 September 2026 placed on the market.
Irrespective of this, the pre-contractual information obligations exist:
- Art. 3(2) — before concluding a purchase, rental or leasing contract for the product: type, format and estimated volume of the data; whether it is generated continuously and in real time; whether it is stored on the device or a remote server and for how long; how it can be accessed, retrieved and deleted.
- Art. 3(3) — before concluding a contract for a related service: type, scope and frequency of collection, access modalities, intended own use by the future data holder and its purposes.
This information belongs in the product information and contractual documents, not in the privacy policy.
3. Provision to the user (Art. 4(1))
Insofar as the user cannot access directly on the product, the data holder must provide: without undue delay, simply, securely, free of charge, in a comprehensive, commonly used and machine-readable format and, if relevant and technically feasible, in the same quality as for the data holder, continuously and in real time. The request may be made informally by electronic means.
Flanking measures:
- Art. 4(4) — prohibition on unduly obstructing the exercise of rights, expressly including manipulative interface design ("dark patterns").
- Art. 4(5) — identity verification only to the extent necessary; no logging of access beyond what is necessary.
- Art. 4(2) — contractual restrictions are permissible if the processing could impair statutory safety requirements of the product and lead to serious health or safety consequences. If the data holder refuses for this reason, it shall inform the competent authority designated pursuant to Art. 37 — in Germany the Federal Network Agency (Section 2(1) DADG).
4. Transfer to third parties (Art. 5, Art. 6)
At the user's request, the data holder shall provide the data to a third party — for the user free of charge, in the same quality, structured, commonly used and machine-readable, insofar as relevant continuously and in real time. The relationship data holder ↔ third party is governed by Art. 8 and Art. 9; the remuneration is owed by the third party, not the user (/datenwirtschaftsrecht:data-act-vertragsklauseln).
Limits:
- Art. 5(3) — a designated gatekeeper is not an authorised third party. It may neither request the user to pass on data nor induce the user to do so by incentives, and may not accept such data. Infringements are punishable under § 15(2) no. 9 DADG, the most severe administrative fine provision of the German implementing law.
- Art. 5(5) — the third party may not use coercive measures and may not exploit gaps in the protection infrastructure.
- Art. 5(6) — the data holder may not use the data to gain insights into the third party's economic situation.
- Art. 5(7) — if the user is not the data subject, a legal basis under Art. 6 GDPR is required.
- Art. 6 — the third party may process the data only for the purposes and under the conditions agreed with the user; the infringement is subject to an administrative fine under § 15(3) DADG.
5. Trade secrets — procedure instead of refusal (Art. 4(6–8), Art. 5(9–11))
The regulation protects trade secrets in three stages:
- Identification. The data holder or the secret holder identifies and marks – also in the metadata – the data protected as a trade secret. Without identification, the defence does not hold.
- Protective measures. Appropriate technical and organisational measures are to be agreed with the user or third party: model contractual clauses, confidentiality agreements, strict access protocols, technical standards, codes of conduct.
- Suspension or refusal. If no agreement is reached or agreed measures are not implemented or are undermined, the transfer may be suspended and, in narrow exceptional cases, refused. The decision must be reasoned, communicated to the requesting party and notified to the competent authority; the evidence must be submitted.
The associated notification and evidence obligations are subject to an administrative fine under § 15(2) no. 4 and no. 5 DADG. Anyone who refuses without reporting risks the sanction in addition to the substantive defeat.
6. Technical protection measures and legal remedies
Under Art. 11 , the data holder may use technical protection measures to prevent unauthorised use or disclosure — however, they may not undermine the access right. In the event of unauthorised use by users or third parties, Art. 11(2) provides for claims for rectification, destruction and cessation.
User's legal remedies: complaint to the Bundesnetzagentur under Art. 38 in conjunction with § 2 DADG, § 6 DADG; dispute resolution under Art. 10 before a body authorised under § 5 DADG; judicial remedy under Art. 39 — before the ordinary courts, insofar as the claim is asserted under civil law.
Deterministic calculation
The Data Act works with the indefinite term "without undue delay" and does not set a day-based deadline. Therefore, only deadlines set by oneself or agreed by contract are to be calculated. The calculator in ../../../scripts/legal_calc/ supports the setting of deadlines in the request letter:
# Angemessene Frist zur Bereitstellung, gesetzt am 15.02.2026, 14 Tage
python -m scripts.legal_calc.cli frist --ereignis 15.02.2026 --menge 14 --einheit tage --land BY
The appropriateness of the period remains a legal assessment and must be substantiated.
Sources
Legal acts
- Regulation (EU) 2023/2854, Art. 2, 3, 4, 5, 6, 7, 10, 11, 37, 38, 39, 43 — EUR-Lex
- DADG § 2, § 5, § 6, § 15
- Regulation (EU) 2022/1925 (DMA), Art. 3 — EUR-Lex
- GeschGehG § 2, § 6
- Art. 6 GDPR
Commentaries and literature
- Hennemann/Steinrötter, Data Act – Handkommentar, Art. 3, Art. 4, Art. 5.
- Specht-Riemenschneider/Hennemann, Data Act, Kommentar, Art. 4 marginal no. on the term "readily available".
- Wiebe, in: Wiebe/Schur, Datenrecht, Chap. Access claims.
- On the relationship between trade secret / access claim: articles in GRUR and ZD 2024/2025 (verify the reference before use)
[unverifiziert – prüfen]
Case law
There is as yet no supreme court case law on Art. 3 to 6 of the Data Act. For the interpretation of the concept of a trade secret, recourse may be had to the case law on § 2 GeschGehG; every specific decision must be verified in juris or Beck-Online before use [unverifiziert – prüfen].
Output format
DATA-ACT-ZUGANGSVERLANGEN — <Mandat> — <Datum>
I. Verlangen
Eingang: <Datum> Absender: <Nutzer / Dritter im Namen des Nutzers>
Rolle geprüft: [Nutzer bestätigt / zweifelhaft — Nachweis angefordert]
Torwächter: [ja — Art. 5 Abs. 3 sperrt / nein]
II. Datenkatalog
Feld / Kategorie | ohne Weiteres verfügbar | abgeleitet | Geschäftsgeheimnis | Ergebnis
<…>
III. Anspruchsgrundlage
[Art. 4 Abs. 1 — Zugang für den Nutzer]
[Art. 5 Abs. 1 — Weitergabe an Dritten]
Format: <maschinenlesbar, gängig, strukturiert>
Echtzeit / kontinuierlich: [ja / technisch nicht durchführbar — Begründung]
IV. Grenzen und Einwendungen
Art. 4 Abs. 2 Sicherheit: [einschlägig — Mitteilung an BNetzA am <Datum> / nein]
Geschäftsgeheimnis: Kennzeichnung [erfolgt / fehlt]; Maßnahmen [vereinbart / offen]
Art. 5 Abs. 2 Testdaten: [einschlägig / nein]
Art. 11 Schutzmaßnahmen: <…>
V. Ergebnis
Bereitstellung: [vollständig / teilweise / ausgesetzt / verweigert]
Begründung: <…>
Mitteilungspflichten: <Art. 4 Abs. 2 / Abs. 8 / Art. 5 Abs. 11 — an BNetzA>
VI. Rechtsbehelfe
Beschwerde Art. 38 iVm § 6 DADG | Streitbeilegung Art. 10 | Klage Art. 39
Bußgeldrisiko: <§ 15 DADG — Tatbestand und Rahmen>
VII. Risiko: 🟢 / 🟡 / 🔴 <Begründung>
VIII.Quellenverzeichnis
Drafting aid — response to an access request (framework)
Sehr geehrte …,
wir bestätigen den Eingang Ihres Verlangens vom <Datum> nach Artikel 4
Absatz 1 der Verordnung (EU) 2023/2854.
1. Umfang
Die nachstehenden Datenkategorien stellen wir Ihnen ab dem <Datum>
über <Schnittstelle> im Format <…> bereit: <Aufzählung>.
2. Nicht erfasste Daten
Die Felder <…> sind keine ohne Weiteres verfügbaren Daten, weil <…>.
3. Geschäftsgeheimnisse
Die Felder <…> sind als Geschäftsgeheimnisse im Sinne des § 2 Nr. 1
GeschGehG gekennzeichnet. Wir schlagen zur Wahrung der Vertraulichkeit
folgende Maßnahmen nach Artikel 4 Absatz 6 vor: <…>.
4. Weiteres Vorgehen
Für Rückfragen und zur Abstimmung der Maßnahmen stehen wir bis zum
<Datum> zur Verfügung. Eine Ablehnung ist mit diesem Schreiben nicht
verbunden.
Risks / typical mistakes
- Access refused across the board. Art. 4 does not provide for a general refusal; only the security exception in paragraph 2 and the trade secret procedure in paragraphs 6 et seq. are permissible — both with notification to the Bundesnetzagentur.
- Trade secret asserted without designation. Art. 4(6) requires prior identification and designation, including in the metadata.
- Everything declared to be "derived data". The classification must be substantiated field by field; in the event of a dispute, the burden of proof falls on the data holder.
- Remuneration demanded from the user. Access under Art. 4(1) and the sharing under Art. 5(1) are free of charge for the user; consideration comes into consideration only in relation to third parties under Art. 9.
- Gatekeeper block overlooked. Art. 5(3) prohibits sharing with designated gatekeepers — with the highest fine range under § 15 DADG.
- Pre-contractual information tucked into the privacy policy. Art. 3(2), (3) requires separate, clear and comprehensible information in the product and contract context.
- Identity verification misused as an access hurdle. Art. 4(5) limits it to what is necessary; excessive logging is inadmissible.
- Case law invented. There is hardly any case law on the Data Act; every decision must be substantiated or marked as
[unverifiziert – prüfen].