The digital transformation of businesses makes it increasingly difficult to analyse individual regulations in isolation from one another. The AI Act, the GDPR, the Digital Services Act (DSA), the Cyber Resilience Act (CRA) and the provisions of the Act on the National Cybersecurity System (KSC) cover different areas and impose different obligations. In practice, however, they very often intersect within the same business processes.

This is particularly evident in the e-commerce sector. An online shop may simultaneously use artificial intelligence systems, profile customers, utilise the services of external technology providers, operate a marketplace, offer products with digital elements and – once certain conditions are met – be subject to cybersecurity regulations.

It is therefore becoming increasingly important not only to determine which regulations apply to a business, but also to identify where their requirements overlap within a single business model.

 

A single business process may be subject to several regulations

A case in point is the seemingly ordinary purchasing process in an online shop.

The customer begins their visit to the website by chatting with an AI-powered chatbot. The AI Act sets out transparency obligations regarding such interactions – as a general rule, a natural person should be informed that they are interacting with an AI system, unless this is already obvious to them. These obligations will apply from 2 August 2026.

Responsibility for designing the system appropriately so that the user receives the required information lies, as a general rule, with the AI system provider. However, a business using a chatbot should determine its role within the meaning of the AI Act. This is of particular importance in the case of solutions made available under the shop’s own brand.

Depending on how the technology is implemented and made available, it may be necessary to analyse whether the business acts solely as a user of the system or also as its provider. Relationships with an external technology provider also require appropriate regulation, including the division of responsibilities relating to ensuring the solution’s compliance with the regulations.

If a chatbot uses customers’ personal data, its operation must also be analysed from the perspective of the GDPR. Factors that may be relevant include, amongst others, the scope of the data processed, the purpose and legal basis for processing, the manner in which external technology providers are utilised, and the security of information transmitted to the system.

Another element of the process may be a product recommendation system. If its operation utilises personal data and involves profiling, issues arising from the GDPR come into play.

In the case of online platforms, such as marketplaces, the DSA’s requirements regarding the transparency of recommendation systems may also apply, including the disclosure of the main parameters determining what information is suggested to the service user. The scope of these obligations, however, depends on the status of the business and the nature of the service provided. The regulations also provide for specific exemptions, including those relating to micro-enterprises and small businesses.

The mere use of a recommendation system in an online shop does not, therefore, automatically mean that the business is subject to all the obligations laid down for online platform providers.

Even at this stage, a single sales process may require several legal regimes to be taken into account simultaneously.

 

Digital products bring a further layer of obligations

The regulatory scope may extend even further if a trader offers products with digital elements.

The Cyber Resilience Act sets out cybersecurity requirements for such products, covering not only the moment they are placed on the market but also issues relating to vulnerabilities and product security throughout its life cycle.

The actual role of the trader within the supply chain is significant in this regard. The CRA imposes specific obligations on manufacturers, importers and distributors.

Particular attention must be paid to the sale of a product under one’s own name or trade mark. An importer or distributor who places a product on the market under their own name or trade mark is, in principle, treated as a manufacturer under the CRA and assumes the manufacturer’s obligations.

It is also worth bearing in mind that the obligations arising from the CRA are being introduced in stages.

From 11 September 2026, manufacturers are obliged to report actively exploited vulnerabilities and serious incidents affecting the security of products containing digital components. This obligation also applies to products placed on the market prior to that date. The majority of the Regulation’s remaining requirements will apply from 11 December 2027.

This means that businesses placing products with digital components on the market should already be reviewing their role in the supply chain, the scope of their responsibility for product security, and the terms of their cooperation with suppliers of software and other components.

If a product with digital elements collects data on its use or its surroundings and is capable of transmitting it – such as a webcam – the Data Act must also be taken into account. From 12 September 2025, the seller of such a product must, prior to concluding a contract, provide the user with information on, amongst other things, the type and scope of data generated by the product, and how to access it. Connected products placed on the market after 12 September 2026 should, furthermore, be designed in such a way that the user has easy access to this data.

For e-commerce, therefore, legal analysis should not stop at the rules governing the running of a shop or the protection of customer data. It may also be necessary to determine who is responsible for the cybersecurity of the product being sold and to what extent.

 

Organisational cybersecurity versus product cybersecurity

The obligations arising from the Cybersecurity Act (KSC) constitute a separate area.

Whether a business is covered by the Act requires, in each case, an analysis of the nature of its operations and fulfilment of statutory criteria, in particular regarding the type of activity, sector and size of the entity. This does not stem solely from the fact that a business uses specific IT systems. In e-commerce, the focus is primarily on digital service providers, including those operating online trading platforms where consumers enter into contracts with other businesses, provided that they are at least medium-sized enterprises. A shop selling only its own product range is, as a rule, not covered by the KSC on this basis, although it may be subject to the Act for another reason, e.g. as a manufacturer operating in a sector specified in the Act.

However, if a business is subject to the KSC, a further dimension of digital risk management arises – this time concerning the security of the organisation, the networks and information systems it uses, risk management, incident response and supply chain security.

In practice, therefore, a business may find itself in a situation where it must simultaneously take into account:

• KSC – at the level of organisational security,
• CRA – at the level of cybersecurity of products containing digital components.

These are two distinct legal regimes which should not be conflated. However, they may intersect within the operations of the same business.

 

A single incident may trigger several reporting obligations

The overlap of obligations arising from different regulations is particularly evident in the case of security incidents.

Let us imagine a situation in which a cyberattack on an online shop’s ordering system leads to a leak of customers’ personal data.

Such an incident may require the reporting of a personal data breach to the President of the Office for Personal Data Protection under the GDPR. If the breach is likely to result in a risk to the rights or freedoms of natural persons, the controller should, as a general rule, make the notification without undue delay, where possible no later than 72 hours after the breach has been detected. If the breach is likely to result in a high risk, the controller should also notify the data subjects without undue delay.

If the business is also subject to the obligations under the Cyber Security Act (KSC), the same incident may trigger separate reporting procedures relating to cybersecurity.

In the case of serious incidents, the provisions of the KSC provide, amongst other things, for the issuance of an early warning within 24 hours and the reporting of the incident within 72 hours of its detection, taking into account specific rules concerning certain entities and the deadlines for the commencement of the new obligations. In certain cases, it may also be necessary to inform service recipients of the incident.

Further obligations may apply if the incident concerns a product with digital components and meets the reporting criteria set out in the CRA.

In the case of actively exploited vulnerabilities and serious incidents affecting product security that fall within this obligation, the manufacturer should issue an early warning within 24 hours of becoming aware of the incident, followed by a formal notification within 72 hours. Reports are submitted via a single reporting platform operated by ENISA to the CSIRT acting as the coordinator.

In practice, a single incident may therefore require a parallel analysis of several regulations, the identification of the appropriate recipients of reports, the scope of the information to be provided, and separate deadlines.

This does not mean that every incident is automatically subject to reporting under all the regulations mentioned. The scope of obligations depends on the status of the business, the nature of the incident and whether the conditions set out in the relevant regulations are met.

Therefore, the incident response procedure should not be limited solely to technical measures. It should also enable the efficient identification of legal obligations and the coordination of activities between teams responsible for security, data protection and regulatory compliance.

During an actual incident, there may no longer be time to determine who is responsible for specific notifications and which deadlines apply.

 

Organisational silos can be a problem

The complexity of the regulatory environment does not stem solely from the number of new regulations. The way in which organisations manage individual areas also presents a significant challenge.

Cybersecurity is often the responsibility of the IT department or the CISO. Data protection is the responsibility of the data controller, whilst the data protection officer advises on and monitors compliance with the GDPR, often in collaboration with the legal department. Marketing is responsible for personalisation and customer communications. Procurement negotiates contracts with technology suppliers, and product teams implement AI-based solutions.

This division of responsibilities is natural. However, risks arise when each team analyses only its own part of the process.

Once again, a chatbot is a good example. It may be implemented by the marketing department, use a model provided by an external company, process customer data and communicate with the order management system.

From the organisation’s perspective, this is no longer merely an ‘AI project’. A single solution may involve issues relating to artificial intelligence, data protection, cybersecurity, confidentiality of information, as well as liability and the allocation of risks in the contract with the supplier.

Whilst each team can correctly assess the issues falling within its remit, the organisation may still fail to recognise the risks arising at the interface between different areas.

It is therefore crucial not only to assign responsibility for specific issues, but also to establish rules for cooperation and the exchange of information between teams.

 

A common model for digital risk management

The AI Act, GDPR, DSA, CRA and KSC have different scopes of application, different target audiences and differing requirements. They should therefore not be treated as a single regulatory regime.

At the same time, their application may require an analysis of the same elements within an organisation.

This applies in particular to:

• the systems and technologies used,
• the flow of data and information,
• risk identification and assessment,
• technology suppliers and the supply chain,
• incident response procedures, the identification of reporting obligations and the deadlines for fulfilling them,
• the allocation of responsibilities within the organisation,
• and the documentation of decisions taken.

Therefore, a business should not always start by creating a separate project for each new regulation.

A more effective starting point may be a map of the company’s processes, technologies and digital risks, followed by the assignment of specific regulatory requirements to them.

A joint inventory of systems can serve several purposes. An assessment of a technology provider can simultaneously take into account issues of cybersecurity, personal data protection, the terms of use of AI, and the allocation of contractual liability.

Similarly, an incident response procedure can set out not only how to identify and mitigate threats, but also the rules for determining which reporting obligations must be triggered, within what timeframes, and who is responsible for fulfilling them.

This does not mean replacing separate legal obligations with a single universal procedure. Individual regulations still require the fulfilment of their specific conditions and adherence to defined standards.

A coherent management model can, however, reduce the duplication of the same analyses, streamline cooperation between teams and, above all, help to identify areas that might otherwise fall outside the scope of responsibility of individual organisational units.

 

The board’s perspective: one roadmap instead of many independent projects

It is therefore crucial for the board to obtain a comprehensive overview.

This does not mean that it is necessary to manage every requirement arising from the AI Act, the GDPR, the DSA, the CRA or the KSC at an operational level. Individual obligations still require specialist knowledge and may remain within the remit of different teams.

However, management’s responsibility is not solely of an organisational nature.

The amended Act on the National Cybersecurity System provides for the liability of managers of key and important entities for the fulfilment of specific cybersecurity obligations. Delegating the fulfilment of these obligations to employees or external specialists does not relieve the entity’s manager of their statutory liability.

If the management board consists of several members and no person has been designated as responsible for carrying out these duties, all its members are liable.

The scope of duties and the deadlines for their fulfilment must be assessed in the light of the transitional provisions of the amendment to the National Cybersecurity Act. Entities that met the statutory requirements on the date the amendment came into force generally have until 3 April 2027 to implement the required organisational and technical measures, and financial penalties, including those imposed on the head of the entity, may be imposed no earlier than 3 April 2028.

From a business management perspective, it is therefore important to determine which regulations apply to a specific business model, where their requirements intersect within the same processes, and who is responsible for the risks arising at these points of intersection.

The management board should have access to information enabling it to assess whether the adopted division of responsibilities is effective, whether individual teams are cooperating with one another, and whether significant risks are escalated to the appropriate decision-making level.

In practice, therefore, the first question should not always be:

“Which regulation do we need to implement next?”

It is worth answering other questions first:

“Is there anyone in our organisation who can see all the digital risks at the same time?”

The lack of such an overview may lead to a situation where individual responsibilities are carried out correctly, but there remain areas between them for which, in practice, no one is accountable.

---

How can JLSW support businesses?

JLSW supports businesses in identifying obligations arising from digital regulations and in assessing their impact on specific business models.

As part of our consultancy services, we assist with regulatory mapping of business activities, identifying areas subject to the AI Act, GDPR, DSA, CRA and KSC, analysing processes that utilise AI and data, and assessing relationships with technology providers.

We also support businesses in designing coherent digital risk management policies, defining the division of responsibilities between teams, and preparing organisational solutions and procedures that enable them to effectively comply with legal requirements.

Our aim is to translate complex regulations into solutions that reflect how the business actually operates – so that individual teams know when and how they should work together, and senior management has the information necessary to make informed decisions.