Back to blog

EU Data Act for Software Companies: Preparing Data Access and Cloud Switching

Data SovereigntyComplianceSoftware ArchitectureBackend Development

Since 12 September 2025, the EU Data Act is no longer a later compliance topic for software companies. Teams operating connected products, IoT platforms, SaaS integrations or cloud services need to explain which data is created, who may use it and how it can be provided or transferred technically.

What the EU Data Act Means for Software Companies

The EU Data Act is not simply another privacy rule. It creates rules for who can use, port or transfer data from connected products, related services and data processing services from one provider to another.

For growing software teams, this becomes an architecture task. Product data needs to be discoverable, classifiable and available through stable interfaces. At the same time, GDPR, trade secrets, security requirements and customer contracts remain relevant.

Leadership and engineering should focus on these questions:

  • Data scope: Which raw data, metadata and pre-processed data are created through product usage?
  • Access model: Can users or authorised third parties receive data without manual special processes?
  • Tenant boundaries: Are customer datasets technically separated or only protected by convention?
  • Portability: Is data machine-readable, documented and free from unnecessary cloud dependencies?

The EU Data Act does not replace good data architecture. But it exposes where a system only worked internally and is not explainable to customers, partners or regulators.

Where Teams Should Start With Data Access and Cloud Switching

The most common mistake is treating the EU Data Act as legal text work. The expensive gaps usually sit in the backend: unclear event schemas, manual exports, data copies without owners, missing deletion logic or provider-specific formats that nobody can migrate cleanly.

A pragmatic starting point is a small inventory for product-critical data flows:

data_access_inventory:
  product_area: fleet_monitoring
  owner: platform-team
  data_classes: ["sensor_data", "usage_metadata", "maintenance_events"]
  export_format: "jsonl"
  tenant_boundary: "database_schema_per_customer"
  cloud_dependency: "managed_timeseries_database"

That creates concrete decisions:

  • API instead of ticket process: Recurring data access needs a product-ready interface, not a manual support export.
  • Data classification before export: Personal data, trade secrets and security-relevant data must not be handled in the same process.
  • Schema governance: Events and export formats need versioning, deprecation rules and clear owners.
  • Test switching paths: Cloud switching remains theoretical if backups, object structures, IAM and runtime services have never been tested outside the current provider.
  • Synchronise contracts and technology: What sales promises, legal writes and engineering can deliver must fit together.

This is especially relevant for manufacturers and platform providers that later want to participate in Catena-X, Manufacturing-X or other data spaces. Sovereign data exchange only works when rights, interfaces and operational responsibility are already designed into the product.

Why This Matters

The EU Data Act shifts data access from a special request to an expected product capability. For decision-makers, this is not only about penalties, but about contractual readiness, cloud negotiation power, partner integration and trust with enterprise customers. Teams that organise their data flows early reduce later migration cost and can evaluate new data-based business models faster. Teams that wait will retrofit compliance into grown systems under time pressure. That is more expensive, slower and riskier than an architecture that takes data access, interoperability and cloud switching seriously from the beginning. An Architecture & AI Review can assess whether data flows, interfaces and cloud dependencies are already robust enough.