Data Act: What IT teams need to implement now

The Data Act applies from September 12, 2025. It breaks down data silos, obliges manufacturers and operators to provide data access, and reaches deeply into processes from IoT to cloud. Organizations benefit when they harmonize data inventories, interfaces and security controls early.

Brief overview

Applicable from September 12, 2025; design obligations for new products from September 12, 2026.
Users receive access to product and service data; transfer to third parties is possible upon request. Gatekeepers are excluded.
Cloud switching and multi-cloud are strengthened, with requirements for fair terms and fees.
No standalone legal basis for personal data; GDPR remains the primary framework.
The EU recommends model contract clauses; drafts are available, while some final details are still in flux.

Why the topic is relevant now

When the Data Act starts to apply on September 12, 2025, the grace period ends. Companies must provide data access, secure it contractually and protect it technically. Delays affect not only compliance, but also business models: maintenance, after-sales services and data-driven offerings will depend on transparent, secure data flows in the future.

In addition to the Data Act, the Cyber Resilience Act is another EU regulation that introduces new obligations for manufacturers and directly affects the secure operation of solutions such as Sophos Firewall.

What is changing or new

Data access: Users of connected products receive access to raw and certain processed data generated during use. Direct provision to third parties is required upon request. Gatekeepers under the DMA are excluded as recipients.
Product design: From September 12, 2026, connected products must be designed so that data is directly available by default.
Cloud switching: The Data Act reduces lock-in effects, promotes multi-cloud and regulates fair switching conditions.
Contract rules: Data license agreements between the data holder and the user become mandatory. The EU publishes non-binding model clauses to support implementation.

Technical overview

Terms and Roles

Data holder: Entity with control over access to product or service data, often the manufacturer or operator. Service providers responsible for operations can also be data holders. Going forward, they must establish processes that give users access without delay.
User: Lawful user of the product or service, including companies. This also includes fleet operators, farmers or end customers working with connected devices. Users receive not only a right to information, but a direct right of access to their data.
Third party: Recipients authorized by users to receive the data, but not gatekeepers. Third parties can be service partners, independent workshops, research institutions or software providers. They must be integrated through secure interfaces.

Data types

Covered: Product data and related service data generated during use, including sensor data, status messages, location data and metadata. Processed datasets are also included if they are intended for reuse.
Not covered: Content data such as documents, images or communications. These remain outside the scope.
GDPR interface: Personal identifiability is often possible; the Data Act does not create its own legal basis. Every disclosure must also be GDPR-compliant, including a review of the legal basis and, where necessary, consent.

Interfaces

Direct access is preferred; otherwise data must be provided in a standardized, machine-readable format and, where possible, in real time. For companies, this means setting up APIs, data export functions and clearly documented processes. Monitoring, authentication and authorization checks are also part of the interface architecture.

Practical Guide

Preparation

Data inventory: List systems, products, sensors and data schemas. Anticipate personal data implications and review aggregation levels. External data sources, archive systems and backup data should also be considered.
Classification: Separate product and service data from content data. Assign GDPR relevance and legal bases for each dataset. Also document categories and lifecycles.
Contracts: Prepare data license clauses for new and existing contracts; review draft MCTs and adapt them where necessary. Also create internal guidelines and training for contract owners.

Implementation

Interfaces: Establish APIs or exports, implement AuthN/AuthZ and document output formats. Also provide versioning and test environments.
Authorization of third parties: Set up processes for consent or authorization checks; embed gatekeeper checks as a fixed step. Also use role-based access patterns and time-limited tokens.
Cloud switching: Plan switching paths, data transfer, and mapping; define multi-cloud strategies. Schedule test migrations and performance checks.
Trade secret protection: Evaluate filters for trade secrets, minimization and pseudonymization. Review technical methods such as data masking or differential privacy.
Change management: Document and communicate processes for updates and changes to interfaces.

Validation

Test cases: User self-service, third-party approval, revocation and error scenarios. Also include edge cases and load tests.
Logging: Document outputs, recipients, timestamps and legal basis in an auditable manner. Implement tamper-evident storage and regular reports.
Security tests: API penetration tests, rate limiting and anomaly detection. Consider automated vulnerability scans and bug bounty programs.
Compliance checks: Internal audits to ensure GDPR and Data Act compliance.

Rollback and Monitoring

Rollback path in case of erroneous disclosures. Document recovery and incident response scenarios.
Monitor data outflows via firewall, IDS and SIEM; alert on volume or pattern deviations. Also implement real-time dashboards and escalation processes for security teams.

Recommendations and Best Practices

Recommended measures

Data inventory and categorization as a mandatory step.
API-first approach with consistent schemas.
Least privilege and finely granular consent.
Automate gatekeeper checks.
Logging and audit-ready evidence.
Test multi-cloud switching early.

Compact mapping table

Measure	Purpose	Note
Data inventory	Transparency and scope	Basis for GDPR review
MCT review	Contract clarity	Use EU drafts, adapt locally
API rate limits	Abuse protection	Combine in firewall and API gateway
Gatekeeper filter	Compliance	Check against DMA lists
SIEM correlation rules	Traceability	Integrate into existing playbooks
Design from 2026	Future readiness	Direct access by design

Impact on Sophos and other platforms

Firewall policy: New data endpoints and admin APIs need rules, TLS inspection after risk assessment, and Threat Feeds for anomaly detection. Tight segmentation and application control rules for API-based access are also recommended.
Zero Trust: Segmented zones and mTLS for third-party access. Also use regular certificate rotation and integration with existing identity providers to control granular permissions.
SIEM/EDR: Correlate events related to data disclosures, especially unusual volumes or recipients. Extended use cases should also cover API errors, authentication attempts and unauthorized queries.
Cloud: Establish egress controls and contractual exit checklists for switching scenarios. Also consider capacity planning, automated tests of exit processes, and policies for data classification and encryption.
Backup and archiving: Data disclosed under the Data Act should be protected by consistent backup and archiving strategies. This enables recovery in case of erroneous disclosures or misuse.
Reporting: IT teams should create regular reports on data outflows and pass them to compliance and management stakeholders. This ensures transparency and traceability.

Frequently Asked Questions

How do you distinguish personal from non-personal data?

Check context and linkability. Location and usage data can often be linked to individuals. No disclosure without a suitable GDPR legal basis.

Do you have to deliver data to any third party?

Only at the user’s request and in compliance with the requirements. Gatekeepers are excluded.

From when is direct access mandatory?

For new products and services placed on the market from September 12, 2026. Until then, provision upon request must work.

Are there model clauses?

Yes, the EU is working on non-binding MCTs and cloud SCCs; an EDPB statement on the draft is available.

What role does cloud switching play?

The Act promotes provider switching and multi-cloud. Fees must be fair and non-discriminatory.

Conclusion

The Data Act shifts control over product and service data toward users and opens markets for services around maintenance, analytics and integration. For IT teams, this means work on three fronts: data inventory and legal basis, secure interfaces, and operationalized monitoring. New responsibilities also arise in compliance management, process documentation and employee training. Interaction with cloud services and integration into existing security architectures must be planned early as well. Organizations that standardize, automate and build in safeguards early reduce effort and risk while positioning themselves for future regulatory developments and new business models in a data-driven environment.