Leaving your GRC vendor may be about to get cheaper.
Taking your audit trail with you is a separate problem. It is the one that decides whether you can actually leave.
The EU Data Act takes away the exit fee. It cannot make three years of control tests and sign-offs mean anything outside the tool that structured them.
This piece is for third-party risk and procurement owners reviewing SaaS vendors, including their own compliance tooling.
What actually ends on 12 January 2027, and what does 'switching charges' not cover?
Article 29(1) of the Data Act is short: "From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process."
Until that date, Article 29(2) allows "reduced switching charges", and Article 29(3) limits them: they "shall not exceed the costs incurred by the provider of data processing services that are directly linked to the switching process concerned."
Only those charges go to zero, and the definition is narrow. Article 2 defines switching charges as "charges, other than standard service fees or early termination penalties, imposed by a provider of data processing services on a customer for the actions mandated by this Regulation for switching". That definition does include "data egress charges".
So two costs stay legal:
→ Standard service fees. → Early termination penalties.
Article 29(4) requires providers to disclose both before signature. It does not ban them.
Egress has its own carve-out. For services used in parallel, Article 34(2) says providers "may impose data egress charges, but only for the purpose of passing on egress costs incurred, without exceeding such costs."
The rest of the switching regime is already live. Article 50 says the Regulation "shall apply from 12 September 2025." Only the zero-charge rule waits for January. The Article 25 contract terms (notice, transition, retrieval, erasure) should already be in your contract; our August analysis of cloud exit clauses covers them.
Is your GRC platform a 'data processing service' under the Data Act, and how would you test it?
We will not tell you whether your GRC vendor is in scope, including us. The Regulation gives you a test.
Article 2 defines a data processing service as "a digital service that is provided to a customer and that enables ubiquitous and on-demand network access to a shared pool of configurable, scalable and elastic computing resources of a centralised, distributed or highly distributed nature that can be rapidly provisioned and released with minimal management effort or service provider interaction".
Turn that into questions for the vendor:
→ Is the service delivered over the network, on demand? → Does it run on a shared pool of configurable, scalable and elastic resources? → Can it be provisioned and released with minimal management effort or provider interaction?
Then check Article 31.
Article 31(1) disapplies Article 29 where "the majority of main features has been custom-built to accommodate the specific needs of an individual customer" and the service is not offered "at broad commercial scale". A bespoke build for one group may fall here. Catalogue SaaS is a different case.
Article 31(2) takes the whole switching chapter off non-production versions "for testing and evaluation purposes and for a limited period of time". Your pilot is not your exit test.
Under Article 31(3) the provider must tell you, before the contract, which obligations do not apply.
Which parts of your compliance record count as 'exportable data', and does that include metadata?
This is the definition that matters for compliance teams.
Article 2 defines exportable data as "the input and output data, including metadata, directly or indirectly generated, or cogenerated, by the customer’s use of the data processing service".
Read it against a GRC record:
→ Input data. Your organisational profile, questionnaire answers, uploaded evidence, policy documents. → Output data. Risk scores, gap lists, control status, reports produced from your inputs. → Metadata. Article 2 defines metadata as "a structured description of the contents or the use of data facilitating the discovery or use of that data". In a GRC tool that is the timestamps, the owners, the links between a piece of evidence and the control it satisfies.
That third item is your audit trail. On a plain reading of the definition, it sits inside exportable data, not outside it.
The limit: exportable data excludes "any assets or data protected by intellectual property rights, or constituting a trade secret, of providers of data processing services or third parties". Article 25(2)(f) lets the contract exempt "categories of data specific to the internal functioning of the provider’s data processing service" where "a risk of breach of trade secrets of the provider exists". That exemption must not "impede or delay the switching process".
Read the exemption list closely. Proprietary control frameworks, mappings and scoring logic may be on it. Your evidence leaves. The structure that gave it meaning may not.
Why does a free exit not matter if your evidence only makes sense inside the vendor's model?
Here is the structural problem.
Many GRC platforms store your posture as answers to the vendor's questions, mapped to the vendor's control library, scored by the vendor's logic. The export is real. It is a spreadsheet keyed to identifiers that mean nothing anywhere else.
You can take the file. You cannot take the reasoning.
The Data Act sees this coming. Article 2 defines "functional equivalence" as re-establishing "a minimum level of functionality in the environment of a new data processing service of the same service type" on the basis of your exportable data and digital assets. Article 23(d) requires providers to remove obstacles to achieving it, in accordance with Article 24.
A minimum level of functionality is a floor. An auditor wants to know why a control was marked effective in March, which regulation required it, and what evidence backed it. If that chain lives in a proprietary mapping, the export is facts without reasons.
That is vendor lock-in no switching charge rule can reach. It was never priced. It was built into the data model.
What should a portable, source-cited GRC record look like: obligations, controls, evidence, timestamps?
The fix is not a better export button. It is a record that carries its own meaning, where every link points to something the next system, or the next auditor, can verify without the source vendor:
→ Obligation → source text. Each obligation carries the article reference and a verbatim quote from the regulation. Any tool, or any lawyer, can check it. → Control → obligation. Each control states which obligations it addresses, by reference, not by an internal ID. → Evidence → control. Each piece of evidence states which control it supports, who submitted it and when. → Decision → timestamp. Every status change is dated and attributed. History is appended, not overwritten.
The anchor is the regulation, and nobody owns that. Key obligations to verbatim source text, not a proprietary taxonomy, and the record makes sense in any system that can read a citation.
This is how Aigis is built. Every obligation, across 245+ regulations in 28 jurisdictions, traces to a verbatim citation. Risks bind to obligations, obligations to regulations, regulations to source text. The audit pack is a query, not a project, and it returns citations, not our opinion of them.
On the provider side, Article 30(2) requires providers outside the pure-infrastructure category to "make open interfaces available" to customers and destination providers "free of charge to facilitate the switching process." Article 26(b) requires a reference to an online register of "all the data structures and data formats" for exportable data. Ask for both.
Who should hold the trust boundary: your agents inside your perimeter, or the vendor's agents in your stack?
There is a second form of lock-in, and it is newer.
Much of today's compliance automation runs the vendor's agents across your systems, with standing credentials into your cloud accounts, ticketing and identity provider. The evidence they gather lands in the vendor's model.
Now try to leave. You are revoking a third party's access to your stack and rebuilding collection logic that lived on their side. Your cloud exit strategy now includes an access review.
The other model inverts the trust boundary. Your own agents run inside your perimeter, under your IAM, logging and DLP. They do the labor: asset discovery, evidence collection, control status. Then they push attested signal to a deterministic engine over MCP or an API. Bring your own agent - Claude Code, or any MCP client.
The collection logic is yours. The credentials never leave. The engine holds a source-cited record of what your agents reported and which obligation it satisfied.
Your agents do the work. Our engine keeps it honest.
Determinism lets you trust what the agents submit. Source citations let that record survive a switch.
What should third-party risk teams ask a GRC or compliance-automation vendor before renewal?
Before renewal, put these in writing:
- Scope. Do you consider your service a data processing service under Article 2? If not, which Article 31 exclusion do you rely on?
- Exportable data list. Show us the Article 25(2)(e) specification. Does it include metadata: timestamps, owners, evidence-to-control links?
- Trade-secret exemptions. What is on the Article 25(2)(f) list? Are your control mappings or scoring logic on it?
- Charges after 12 January 2027. Which costs remain as standard service fees or early termination penalties?
- Formats. Where is your Article 26(b) register of data structures and formats?
- Citations. Does each exported obligation carry its regulation reference and source text, or only your internal ID?
- Access. Which credentials into our environment do your agents hold today, and what does revoking them break?
Questions one to five test the Regulation. Six and seven test whether the exit works. Weak answers there mean your audit trail is portable on paper only.
Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you. No call required. Start at agrc.ai/third-party-risk, or see how the platform and risk management record is structured.
FAQ: EU Data Act switching and GRC platform exit
Do EU Data Act switching charges disappear completely on 12 January 2027? Switching charges do. Article 29(1) bars them "From 12 January 2027". Standard service fees and early termination penalties sit outside the Article 2 definition. Egress charges for parallel use may still pass on actual cost under Article 34(2).
Does exportable data include my audit trail? Article 2 defines exportable data as input and output data "including metadata". Timestamps, owners and evidence links are the kind of "structured description" that definition describes. Provider trade secrets and IP-protected assets are excluded, so check the contract's exemption list.
Is my GRC tool covered by the switching rules? Only if it meets the Article 2 definition of a data processing service and no Article 31 exclusion applies. Ask the vendor to state its position in writing.
A posture you can defend in front of a regulator, a board, or a plaintiff should not depend on staying with one vendor.
