EU Data Act Audit Evidence and Request Logs FAQ

A request log should show the route from intake to outcome. For connected-product and related-service data, record whether the requester is the user, a party acting on the user's behalf, or a third party chosen by the user. The log should identify the product or related service, requested data and metadata, format, timing, delivery route, and any refusal, suspension, limitation, compensation, or dispute route.

Keep the log narrow. The Data Act allows data holders to verify user or third-party status, but it also says they should not require more information than necessary and should not keep access information beyond what is necessary for execution, security, and maintenance of the data infrastructure.

Trade secret handling needs its own evidence trail. The log should identify the data marked as trade secrets, the trade secret holder, the agreed technical and organisational measures, and whether the measures were accepted, not implemented, undermined, or still insufficient in exceptional circumstances.

A refusal or suspension should not be logged as a bare legal conclusion. The Data Act requires written substantiation for withholding, suspension, or case-by-case refusal based on serious economic damage, and notification to the competent authority in specified trade secret refusal scenarios.

For public-sector exceptional-need requests, keep the incoming written request and a structured review record. The record should show the requesting body, legal task, exceptional-need basis, specific data and metadata requested, purpose, intended use, deadline, erasure expectation, onward-sharing plan, and whether personal data, trade secrets, or cross-border procedure steps are involved.

The Data Act gives data holders short challenge windows for these requests. A holder may decline or seek modification no later than five working days after receiving a public-emergency request, and no later than 30 working days for other exceptional need requests, when the statutory grounds apply.

For data processing services, the audit file should connect the customer's switching notice to the contract clauses, export inventory, transition timeline, assistance provided, risks communicated, security controls, retrieval period, erasure step, and switching charges. It should also show whether the service is IaaS, PaaS, SaaS, custom-built, or a limited testing version because the technical obligations can differ.

The Data Act requires contracts to include switching clauses, a maximum notice period not exceeding two months, a mandatory maximum transition period of 30 calendar days, at least 30 calendar days for data retrieval, and a 14 working day notification if the 30-day transition is technically unfeasible and an alternative transition period is needed.

Keep a contract-term register for data access, use, compensation, remedies, termination, switching, and cloud exit. For B2B data access and use, the register should flag terms that were unilaterally imposed and explain whether they could be unfair under Article 13. For cloud contracts, keep the written switching clauses and the website disclosures that the contract points to.

Do not treat Commission model terms or standard contractual clauses as mandatory templates. The Commission FAQ says the model contractual terms and standard contractual clauses are non-binding and adaptable, so the audit file should show whether they were considered, accepted, adapted, or not used.

The Data Act does not supersede GDPR analysis. If the requested dataset contains personal data, the log should show the GDPR legal basis, special-category conditions if relevant, ePrivacy check where relevant, data minimisation steps, and whether anonymisation or pseudonymisation was used before disclosure.

When the user is not the data subject, the Data Act does not itself create a legal basis for giving that user or a third party access to another person's personal data. The log should show whether the personal data were filtered, anonymised, pseudonymised, limited to the user's own data, or escalated to privacy counsel.

The log should retain enough to prove compliance, but not become an unnecessary surveillance record. For user and third-party access requests, the Data Act expressly limits verification information and access logs to what is necessary for sound execution of the request and for security and maintenance of the data infrastructure.

For B2G requests, retain the request, review, transfer, onward-sharing notice, erasure notice, complaint correspondence, and compensation basis where relevant. For smart contracts used to execute data sharing agreements, retain transactional data, smart contract logic, and code where necessary to preserve auditability after termination or deactivation.

Start with one register that can route a request into separate workflows. The register should not decide the law by itself; it should preserve the facts needed for legal, support, product, security, procurement, cloud, and privacy owners to make the decision.

A practical schema uses required fields, controlled values, and attachments. It should be tested against at least five cases: user access to connected-product data, user-directed third-party sharing, trade secret limitation, B2G exceptional need request, and cloud switching or export request.