Search every question across sub-FAQs

Under the Data Act, a third party may use received data only for purposes agreed with the user, and Article 6 includes prohibitions such as using the data to develop a competing connected product and sharing it with a Digital Markets Act gatekeeper. Where the received data is personal data, the third party must also satisfy GDPR controller or processor obligations for its own processing.

Before sending data to a third party, the data holder should confirm the user's instruction, identify the receiving entity, record the agreed purpose, restrict further use, and handle any GDPR transfer or recipient information duties. If the user is not the data subject, the lawful-basis analysis becomes decisive.

The evidence file should show how the team separated the Data Act question from the GDPR question. Keep the request form, requester identity and role, data-scope decision, field-level classification, lawful-basis check, minimisation step, trade-secret or security review, third-party recipient details, and the final decision to disclose, limit, anonymise, or refuse.

Use one short decision note per request that points to the controlling legal rule and the operational action taken. That keeps the file auditable without burying the reviewer in free-form commentary or repeating template language.

Keep the source evidence tied to the legal point the team actually used. That means the Data Act article or recital, the Commission FAQ question or fact page, the request date, the internal owner, and the specific data categories affected.

The record should also show why the decision was made, not just what text was cited. If the team relied on anonymisation, minimisation, a GDPR lawful basis, or a trade-secret safeguard, the file should say so plainly and link it to the relevant source URL.

Assign one accountable owner for the process change, usually the team that can actually update the intake form, workflow, contract, or API rule. For Data Act/GDPR overlap, that is often privacy, legal, product, support, procurement, security, or data governance, depending on where the request enters the business.

Ownership should be clear even when several teams are consulted. The accountable owner should decide whether the request can move forward, needs redaction or anonymisation, or must be escalated for a GDPR or trade-secret review.

The Data Act context is the starting point for this answer. A request log should prove 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.

The Data Act context is the starting point for this answer. 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.

The Data Act context is the starting point for this answer. For public-sector exceptional need requests, keep the incoming written request and a structured review record. The file 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.

The Data Act context is the starting point for this answer. 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.

The Data Act context is the starting point for this answer. 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.

The most important boundary is when the user is not the data subject. In that case, the Data Act does not itself create a legal basis for giving the 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.

The Data Act context is the starting point for this answer. 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 right decision quickly.

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.

For audit evidence and request logs, teams should keep the exact source URL, the Data Act article or recital relied on, the question being answered, the owner who approved the interpretation, and the date the decision was made. The file should also show which workflow the decision affects so a future reviewer can reopen the same legal conclusion without starting over.

Teams should not rely on a one-line citation alone. Keep the specific extract, the implementation note, and any follow-up check that shows how the decision was applied in a request log, contract register, or switching file.

For audit evidence and request logs, the Data Act workflow should name one accountable owner for each decision point. That owner should be the person who can update the log template, approve the evidence standard, or sign off the relevant legal interpretation when the workflow changes.

If more than one team is involved, record consulted teams separately. Legal, privacy, product, support, security, cloud, and procurement may all contribute, but the file should still show a single named owner for the final implementation decision.

For Data Act audit evidence and request logs, the most useful evidence is evidence that can be reused in the next case. Keep artifacts that show how the team classified the request, what fields were required, what exception or safeguard was applied, and what source text supported the choice.

The goal is not to collect every document. It is to preserve the minimum set that lets a later reviewer reproduce the same decision in a similar case without guessing which article, deadline, or authority applied.

For audit evidence and request logs, the Data Act answer should be reviewed when a workflow changes, when the source text changes, or when a new request pattern appears that the current template does not capture well. The answer should also be revisited after team ownership changes or when a new regulator or helpdesk position affects the interpretation.

A review date alone is not enough. The team should also set an event trigger, such as a contract refresh, a cloud migration, a new B2G request type, or a Data Act enforcement update, so the review happens when the evidence really needs to change.

Data Act Article 25 requires the customer switching rights and provider obligations to be clearly set out in a written contract that the customer can store and reproduce before signing. The contract must cover switching to another provider, porting to on-premises ICT infrastructure, or erasing exportable data and digital assets when the customer does not switch.

The clause set should not be a generic portability statement. It needs specific terms for reasonable assistance, business continuity, known continuity risks, security during transfer and retrieval, exit strategy support, termination, notice, exportable data and digital assets, exempt internal-functioning data, retrieval, erasure, and any switching charges allowed under Article 29.

The Data Act cloud switching chapter applies to providers of data processing services. The Commission FAQ explains that this concept covers IaaS, PaaS, and SaaS where the service has cloud-computing characteristics such as on-demand network access to configurable, scalable, elastic computing resources provided to a customer.

Do the scope check before redlining clauses. A consumer-facing app feature that merely relies on cloud infrastructure may not be the same as a customer contracting for a data processing service, while an enterprise SaaS, PaaS, or IaaS service can fall into Chapter VI when the customer relationship and service characteristics are present.

Data Act Article 25 requires the source provider to provide reasonable assistance to the customer and customer-authorised third parties during switching. The same clause should require due care to maintain business continuity, continued provision of contracted functions or services during the transition, clear information on known source-provider continuity risks, and a high level of security during transfer and retrieval.

For IaaS, Article 30 adds a technical assistance layer: providers must take reasonable measures to help the customer achieve functional equivalence in the destination service covering the same service type, including capabilities, information, documentation, technical support, and where appropriate tools. For PaaS and SaaS, the Commission FAQ says the duty does not require rebuilding the customer service inside the destination provider environment.

Data Act Article 25 caps the notice period for starting switching at two months. After that notice period, the mandatory maximum transitional period is 30 calendar days, during which the provider must perform the actions needed to enable switching while the contract remains applicable.

If a 30-day transition is technically unfeasible, the provider must notify the customer within 14 working days of the switching request, justify the technical unfeasibility, and identify an alternative transition period that does not exceed seven months. The customer also has a right to extend the transitional period once for a period the customer considers more appropriate.