Software vendor compliance: the 5 regulations to master

Why the 'Software Publishers' sector is affected

The high regulatory density stems from the very nature of software products. An AI feature triggers the AI Act. Hosting and processing customer data triggers the GDPR (as a processor) and the Data Act (portability, provider switching). Placing software on the market triggers the CRA (security by design, patches, vulnerability notification). The status of digital service provider or ICT service manager triggers NIS2 beyond the size threshold.

For a software vendor whose clients include banks or insurers, a sixth layer is added: DORA, not directly, but through contractual obligations. Financial entities must indeed frame their critical ICT providers with specific clauses, and the most systemic ones may be subject to direct supervision.

The risk for a software publisher is to address these texts in isolation and duplicate efforts. The winning strategy is to identify their common foundation — information security, documentation, vulnerability management, logging — and then apply the specific requirements of each regulation accordingly.

GDPR — the publisher as data processor

A publisher that hosts or processes its customers' personal data acts as a data processor within the meaning of the GDPR. It must provide sufficient guarantees, formalise a data processing agreement (Article 28) and govern transfers outside the European Union.

If it determines its own purposes — product analytics, prospecting, training models on customer data — it becomes a data controller for those operations and thus holds both roles simultaneously.

Key obligations

• Article 28-compliant DPA with each client.
• Data processing on documented instructions only.
• Oversight of sub-processors (hosting provider, sub-contractors).
• Framing transfers outside the EU (standard contractual clauses).

AI Act — the software publisher as AI provider

As soon as an AI system is integrated into a product and placed on the market under the publisher's brand, the publisher becomes a provider and bears the most burdensome obligations under the regulation: technical documentation (Annex IV), risk and quality management system, transparency, conformity assessment, and marking.

The intensity depends on the risk level: a chatbot falls under limited risk, while a people-scoring module shifts to high risk. Integrated general-purpose AI models trigger specific documentation obligations.

Key obligations

• Classification of the system by risk level.
• Technical documentation and quality management system.
• Transparency and human oversight.
• Post-market surveillance.

NIS2 — the software vendor as a digital provider

Above the 'medium entity' threshold (≥ 50 employees or > €10 M in turnover), a software vendor providing digital services or ICT service management falls within the NIS2 category of important entities: cyber risk management measures, incident notification, supply chain security, and management accountability.

Below the threshold, the requirement frequently cascades down through contractual clauses from clients who are themselves subject to NIS2.

Key obligations

• Technical and organisational risk management measures (Art. 21).
• Notification of significant incidents (early warning followed by report).
• Software supply chain security.
• Validation and monitoring of the framework by management.

Data Act — data access and portability

The Data Act (EU Regulation 2023/2854) requires data processing services (cloud, SaaS, PaaS, IaaS) to facilitate provider switching, data portability, and interoperability, and prohibits certain unfair contractual clauses relating to data sharing.

For publishers of connected products, it also opens up a right of access for users to data generated by the product and its associated service.

Key obligations

• Data portability and export mechanisms.
• Progressive elimination of switching costs between providers.
• Review of unfair clauses on data sharing.
• Informing users about the data generated and their rights.

CRA — security of products with digital elements

The Cyber Resilience Act (EU Regulation 2024/2847) requires manufacturers of products with digital elements — including software — to implement security by design and by default, vulnerability management, the provision of patches throughout the support period, and notification of actively exploited vulnerabilities.

It results in a cybersecurity CE marking that conditions market access in Europe. Special regimes exist for non-commercial open source.

Key obligations

• Security 'by design' and 'by default'.
• Vulnerability management and disclosure process.
• Software Bill of Materials (SBOM).
• Notification of exploited vulnerabilities and serious incidents.

Comparative overview of regulations

How these regulations interact

These five texts overlap significantly on security and documentation. A single engineering investment — secure development, logging, vulnerability management, component mapping — simultaneously serves GDPR (Article 32, security), the CRA (essential requirements) and NIS2 (risk management measures). Similarly, the AI Act's technical documentation and GDPR records share a substantial portion of their subject matter.

The winning approach is therefore to build a single product compliance foundation — security policy, SBOM, PSIRT (vulnerability management), records of processing activities and AI systems — then to address the specific obligations: AI Act marking, CRA notification to ENISA, Data Act portability clauses. Treating each regulation in isolation means repeating the same mapping exercise five times.

Application timeline

• 1GDPR. In force since May 2018.
• 2DORA. Applicable since 17 January 2025 (impacts the publisher through its financial clients).
• 3AI Act. Prohibitions since February 2025; GPAI since August 2025; high-risk from August 2026.
• 4Data Act. Majority of obligations applicable from 12 September 2025.
• 5CRA. Entered into force in late 2024; notification obligations followed by full requirements by 2026–2027.
• 6NIS2. Transposition into French law is being finalised; anticipate obligations now.

Applicable penalties

Caps vary across the regulations but are all designed to be dissuasive. GDPR: up to €20M or 4% of global turnover. AI Act: up to €35M or 7%. CRA: up to €15M or 2.5%. NIS2: up to €10M or 2% for important entities, with potential personal liability for managers. Data Act: sanctions set by each Member State, with possible alignment to GDPR caps.

For a software vendor, the financial risk is compounded by a commercial risk: a NIS2 or CRA compliance failure can become a blocker in tender processes, and an uncontrolled incident cascades across the entire customer base.

Compliance roadmap

• 1Map the product. Identify processed data, software components (SBOM), AI building blocks, and third-party dependencies.
• 2Build the security foundation. Formalise a security policy, vulnerability management (PSIRT), and logging — serving GDPR, CRA, and NIS2.
• 3Document in text. Produce the specific deliverables: standard DPA, AI Act technical documentation, NIS2 measures, Data Act portability clauses, CRA declaration of conformity.
• 4Organise notification. Implement separate but coordinated incident procedures (GDPR breach within 72 h, NIS2 incident, CRA vulnerability to ENISA).
• 5Oversee and audit. Involve senior management, appoint a DPO and CISO (internal or outsourced), and establish a periodic review.

How Data Comply One supports the sector

Data Comply One centralises GDPR, the AI Act, NIS2, and DORA on a single platform, with an outsourced DPO and CISO. For a software publisher, this avoids managing multiple service providers and redoing the same mapping five times: a shared foundation, audit-ready deliverables, and deadline tracking.

DCO also publishes a library of document templates (registers, DPAs, AI Act documentation, incident procedures) that publishers can directly leverage to accelerate their compliance journey.

Frequently asked questions