Search every question across sub-FAQs

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.

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 record 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 record should still show a single named owner for the final implementation decision.

For Data Act audit evidence and request logs, keep artifacts that can be reused in the next case. They should show how the team classified the request, which fields were required, which exception or safeguard applied, and which source text supported the choice.

Preserve the minimum set that lets a later reviewer reproduce the 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.

Article 25 requires the switching rights and 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.

A generic portability promise is not enough. Article 25 requires terms on reasonable assistance, business continuity, known continuity risks, security during transfer and retrieval, exit-strategy support, termination, a notice period of no more than two months, the transitional period, exportable data and digital assets, excluded internal-functioning data, at least 30 calendar days for retrieval after transition, erasure, and any switching charges permitted under Article 29. The contract must also state that the customer may extend the transitional period once.

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.

Since the Data Act began applying on 12 September 2025 and until 12 January 2027, Article 29 allows reduced switching charges, but those charges must not exceed the costs directly linked to the switching process. From 12 January 2027, providers must not impose switching charges on customers for the switching process.

The Commission FAQ treats egress charges as included in switching charges for a switching operation. It also explains a separate in-parallel-use rule: where a customer uses services in parallel, such as multi-cloud deployment, providers may still pass on data egress costs incurred after 12 January 2027, provided they do not exceed those costs.

Data Act Article 25 requires an exhaustive specification of all categories of data and digital assets that can be ported during switching, including at least all exportable data. The Commission FAQ explains exportable data as input and output data plus metadata generated or co-generated by the customer's use of the data processing service, while excluding data protected as provider or third-party intellectual property or trade secrets.

Digital assets are broader than customer records. The Commission FAQ describes them as elements the customer needs to effectively use its data in the new provider environment, including configuration metadata, security and access-control material, applications, virtual machines, and containers where the customer has the right to use them.