EU law: GDPR, DORA, CRA and AI Act

The General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, is the EU law on handling information about people. It applies directly in every Member State and covers any processing of personal data, meaning information that identifies a person directly or indirectly, by organisations in the EU and by organisations outside it that offer goods or services to people in the EU or monitor their behaviour. Its core ideas are simple: have a lawful reason for each use of data, use only what you need, keep it accurate and no longer than necessary, protect it, be transparent with the people concerned and be able to show all of this. People get rights such as access, correction and erasure. For a security team the GDPR matters twice: security logs are themselves personal data, and a security incident can be a personal data breach with its own notification duty. National laws add rules, for example on employee data, so check yours.

Often yes, and in a security context you should assume so. Personal data is any information relating to a person who can be identified directly or indirectly, and the GDPR names online identifiers among the examples. An IP address does not carry a name, but it can usually be linked to one: inside a company, the address of a laptop points to the person who uses it, and an internet provider can link a public address to a subscriber. The Court of Justice of the EU has held that a dynamic IP address can be personal data for a website operator that has legal means to identify the person behind it. In practice, treat network logs, device names and connection records as personal data: have a lawful basis, limit who sees them, keep them only as long as needed and cover them in your records. NetSenX handles them as personal data under its data processing agreement and stores them in the EU.

A breach of security that leads to personal data being destroyed, lost, altered, disclosed or accessed without authorisation, whether by accident or on purpose. It is broader than a leak: ransomware that encrypts a customer database is a breach even if nothing was copied, because the data became unavailable, and so is an e-mail sent to the wrong recipients or a lost unencrypted laptop. Not every security incident is a personal data breach, since some involve no personal data, and not every breach must be reported. Under Article 33 of the GDPR, the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people; every breach must be documented either way. Decide with your DPO. From the Starter plan, NetSenX prepares a draft Article 33 notification for your DPO from the incident data; assessing the risk and submitting stay with you.

The controller decides why and how personal data is processed; the processor processes it on the controller’s behalf and on its instructions. When your company uses a security service to monitor its network, your company is normally the controller of the network data and the vendor is the processor. The controller carries the main duties: a lawful basis, transparency towards the people concerned, answering their requests, deciding about breach notifications. The processor must follow your documented instructions, keep the data confidential and secure, use sub-processors only with your authorisation, help you with breaches and requests, and return or delete the data at the end. A contract, usually called a data processing agreement, sets this out. The roles depend on facts, not on labels: a vendor that uses your data for its own purposes becomes a controller for that use. For NetSenX, TriStiX S.L. acts as processor and your organisation as controller, as the published data processing agreement states.

It requires measures appropriate to the risk, not a fixed list. The controller and the processor must take technical and organisational measures that fit the state of the art, the cost of implementation, the nature and purpose of the processing and the likelihood and severity of harm to people. The GDPR gives examples: pseudonymisation and encryption, the ability to keep systems confidential, intact, available and resilient, the ability to restore data after an incident, and a process to test and evaluate the measures regularly. So a company has to decide, document and review what is appropriate for its own data, and be able to explain why. Being able to notice a breach is part of this, since you cannot report or contain what you do not see, and a breach often comes to light through unusual network activity. NetSenX can be one of those measures: it detects beaconing, scanning, lateral movement and unusual outbound data volume on every plan. Whether your overall set of measures is appropriate remains your assessment.

Under the GDPR, only in certain cases. They are public authorities, and organisations whose core activities consist of large-scale regular and systematic monitoring of people or large-scale processing of special categories of data, such as health data. Many mid-sized companies fall outside those cases, but national law can add more. In Germany, section 38 of the BDSG requires a data protection officer where, as a rule, at least 20 persons are constantly engaged in the automated processing of personal data, and in some other cases. Check your own country’s law. Even without a duty, someone must own data protection, and a named contact helps when a breach clock is running. If you appoint one, the officer must be involved in data protection matters in good time, act independently and report to the highest management level. A security tool does not change whether you need one, although network monitoring is a topic the officer should review. NetSenX prepares a GDPR breach notification draft for whoever handles that role, from the Starter plan.

Usually yes, as long as the monitoring is necessary for security and proportionate, and you document the balance. The GDPR allows processing that is necessary for the legitimate interests of the controller, unless those interests are overridden by the rights of the people concerned, and its recitals name network and information security as such an interest, to the extent strictly necessary and proportionate. That means writing down a short balancing test: what you monitor and why, why less intrusive means would not do, what safeguards you apply, and how long you keep the data. Monitoring metadata for signs of attack weighs differently from reading message content or watching individual behaviour. Inform employees in your privacy notice, and check national employment law, which may require consulting or agreeing with employee representatives. NetSenX is built to keep the balance on the safer side: it records metadata, never decrypts traffic, and reports AI use per device and program rather than per person. The legal assessment remains yours.

For the most serious infringements, up to EUR 20 million or 4 % of total worldwide annual turnover of the preceding financial year, whichever is higher, under Article 83(5) of the GDPR. That upper tier covers breaches of the basic principles, the lawful basis, people’s rights and international transfers. A lower tier covers other obligations, such as security of processing and breach notification, with lower maximums set in the same article. These are ceilings, not tariffs: the authority decides case by case, weighing the nature, gravity and duration of the infringement, intent or negligence, what was done to limit the damage, earlier infringements and cooperation. Fines are only one consequence; authorities can also order processing to stop, and people can claim compensation. What lowers exposure is ordinary diligence you can prove: knowing your processing, documented security measures, a breach procedure that works, and timely notifications. NetSenX helps with one part, noticing a breach early and preparing the notification draft from the Starter plan; it cannot remove the risk of a fine.

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, is the EU law on the digital resilience of the financial sector. It requires banks, insurers, investment firms, payment institutions and other financial entities to withstand and recover from technology failures and cyber attacks. It applies directly in every Member State and rests on a few pillars: an ICT risk-management framework owned by the management body; classification and reporting of major ICT-related incidents to the competent authority; regular testing of digital operational resilience, with advanced threat-led penetration testing for some entities; managing the risk of ICT third-party providers, including contract requirements and an exit strategy; and voluntary sharing of threat information. For providers that the European supervisory authorities designate as critical, DORA adds direct oversight. For a financial entity, DORA is the specific rulebook, taking precedence over the general NIS2 rules where they overlap. If you supply ICT services to financial entities, expect DORA to arrive through contracts and questionnaires. NetSenX is not a DORA tool as such; its detection can support the monitoring part of an ICT risk framework.

It puts final responsibility for managing ICT risk on the management body, which cannot hand that responsibility to an IT department or a supplier. Under DORA the management body defines, approves and oversees the ICT risk-management framework and is accountable for its implementation. In practice that means approving the digital operational resilience strategy and the policies behind it, setting and reviewing the budget, approving arrangements with ICT third-party providers and the policy for using them, being informed of major incidents and their consequences, and keeping its own knowledge and skills up to date through training. For directors, this is a governance duty that a supervisor can examine: minutes, approved documents and evidence that reports were read and acted on. Ask your compliance function how your organisation documents these decisions, and use the national supervisor’s guidance for the details. NetSenX plays no part in that governance, but its alerts and PDF compliance reports, from the Starter plan, can be one source of the information the management body receives.

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is the EU law on the security of products with digital elements. These are hardware and software that connect to a device or a network, from routers and cameras to apps and operating systems sold in the EU. It places duties on manufacturers, with lighter ones on importers and distributors. Products must be designed with security in mind, ship without known exploitable vulnerabilities and with secure default settings, and receive security updates during a support period the manufacturer defines. Manufacturers must handle vulnerabilities in a structured way, document the components they use and report actively exploited vulnerabilities and severe incidents, as Article 14 sets out. Some product categories, such as security products and network equipment, face stricter conformity assessment, and products that meet the requirements carry the CE marking. The dates on which each part applies are set in its final provisions. If you only buy and use products, the CRA mainly helps you: expect clearer support periods and update promises from suppliers.

Yes, if they place software on the EU market as a product. Installable applications, firmware, operating systems, libraries sold commercially and mobile apps are all products with digital elements, and the company that makes them available under its name is the manufacturer. Duties include a risk assessment, security by design and by default, handling and fixing vulnerabilities for the support period, documenting components, providing security information and instructions to users, and reporting actively exploited vulnerabilities and severe incidents under Article 14. Free and open-source software developed or supplied outside a commercial activity is largely outside the Act, and organisations that support open-source projects for commercial use, called open-source software stewards, have a lighter set of duties. Software you build only for your own internal use is not placed on the market. If you sell software, start by listing your products, their support periods and your vulnerability-handling process, and read the Regulation itself for the details. NetSenX does not assess whether your software complies.

Generally not to a pure online service, but it can reach the cloud part of a product. The CRA covers products with digital elements placed on the market. Software provided only as a service over the internet, without a product the customer installs, is in principle outside it; the security of such services is mainly a matter for NIS2 where the provider is in scope. However, the CRA also covers remote data processing that a manufacturer designs as part of a product, where the product could not perform one of its functions without it: the cloud back-end of a smart camera or of a network sensor that ships with an agent are typical examples. So a company that sells both an installable component and a cloud service may have CRA duties for the combination. Map which parts of your offering are installed by customers and which run only on your side, and read the Regulation’s definitions with care. NetSenX, which ships agents together with a cloud service, applies the same question to itself.

A software bill of materials (SBOM) is a machine-readable list of the components inside a piece of software, such as libraries and their versions, much like an ingredients list. It lets a manufacturer, and anyone it shares the list with, find out quickly whether a newly published vulnerability affects a product. The CRA requires manufacturers to identify and document the components in their products, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies. It forms part of the technical documentation; the Act does not require the manufacturer to publish it, although authorities can ask for it. If you buy software, ask suppliers whether they keep an SBOM and how they use it to track vulnerabilities, rather than insisting on receiving the file itself. Common formats include CycloneDX and SPDX. NetSenX does not generate SBOMs for your products, and a network sensor cannot see which libraries are inside an application.

The Artificial Intelligence Act, Regulation (EU) 2024/1689, is the EU law that regulates AI systems according to the risk they pose. A few practices are banned outright, such as social scoring and certain uses of emotion recognition at work. High-risk systems, listed by area, such as AI used in recruitment, worker management, credit decisions or as a safety component of critical infrastructure, must meet requirements on risk management, data quality, documentation, human oversight, accuracy and security before and after they are placed on the market. Some systems carry transparency duties, for example telling people they are talking to a chatbot. Most other AI, such as spam filters, faces no specific obligations. Separate rules cover general-purpose AI models. Duties fall on providers, who develop and place systems on the market, and on deployers, who use them professionally. Since 2 February 2025, Article 4 has required both to take measures on their staff's AI literacy, which since its amendment in July 2026 means supporting that literacy rather than guaranteeing a set level for each person; other parts apply in stages. Check with your supplier what class their system falls into.

Usually not, but it depends on what the tool decides and about whom. The high-risk categories are defined by use, not by technology: AI used to recruit, promote, monitor or evaluate workers, to assess creditworthiness, or as a safety component in managing critical infrastructure, among others. A tool that spots malware traffic between devices is not in itself one of those uses. It moves closer when its output is used to evaluate individual employees’ behaviour or performance, or when it acts as a safety component of, say, an energy network. So ask two questions of every security tool: does it assess people or machines, and what happens automatically on its output? Ask the supplier for its own classification and the reasoning. NetSenX is designed to watch devices and connections rather than evaluate people, and reports AI use per device and program, not per person. Its AI transparency page describes where it uses AI and what stays under your control; using alerts to judge staff would be your decision and would need its own assessment.

A few, and they apply whatever the risk class. People must be told when they are interacting with an AI system, such as a customer service chatbot, unless it is obvious. Providers of systems that generate synthetic audio, images, video or text must mark the output in a machine-readable way so that it can be detected as artificially generated. Deployers who publish deepfakes must disclose that the content is artificial, and those who publish AI-generated text on matters of public interest must disclose it too, unless a person has reviewed it and taken editorial responsibility. Deployers of emotion recognition or biometric categorisation systems must inform the people exposed. For a company, the practical steps are an inventory of where AI talks to customers or produces published content, a clear notice in those places, and a check that your suppliers mark their output. These duties apply on the date set in the Act’s final provisions. NetSenX publishes its own AI transparency page for the AI features in its service.

That privacy has to be built into how you set up a system and its default settings, not added after a complaint. By design means that when you choose and configure a tool, you put in place measures such as pseudonymisation, data minimisation and access control that suit the risk. By default means that, out of the box, only the personal data necessary for each purpose is processed, kept no longer than needed and not made accessible to an indefinite number of people. For a security tool, practical questions are: does it collect content or only metadata, can you limit who sees what, how long are records kept, and can people outside the security team see employees’ device names? The duty is the controller’s, so document your choices when you deploy. NetSenX’s defaults point the same way: it records metadata rather than content, never decrypts traffic, keeps alerts for the plan’s alert history, and reports AI use per device and program rather than per person; team roles are available from the Starter plan.

Controllers and processors must keep a written record, which may be electronic, of their processing activities and make it available to the supervisory authority on request. For a controller, each entry describes the purposes, the categories of people and of personal data, the recipients, any transfers outside the EU with their safeguards, the planned deletion periods where possible, and a general description of the security measures. Processors keep a shorter record of the processing they carry out for each controller. Smaller organisations, below an employee threshold set in the GDPR, are exempt in some cases, but the exemption does not apply where processing is not occasional, which is true of almost any continuous network monitoring, or where it is likely to result in a risk or involves special categories of data. So list security monitoring as its own processing activity: purpose, data collected, who sees it, the vendor as processor, where the data is stored and for how long. NetSenX’s data processing agreement and its list of sub-processors give you the vendor facts for that entry; the record itself is yours to keep.

Each looks at a different object, so one company can be under several at once. NIS2 is about the cybersecurity of organisations in listed sectors: risk-management measures, management responsibility and reporting of significant incidents under Article 23. The GDPR is about personal data, wherever it is processed, including the duty to notify personal data breaches under Article 33. DORA is the specific rulebook for financial entities and takes precedence over NIS2 where they overlap. The CRA is about products with digital elements and places duties on the companies that make and sell them. The AI Act is about AI systems and puts duties on their providers and deployers according to risk. A ransomware attack on a hospital supplier may therefore trigger a NIS2 report and a GDPR notification on the same day, and a product flaw behind it may be the manufacturer’s CRA report. Map which laws apply to you, who owns each, and how one incident record can feed several reports. NetSenX tracks NIS2 deadlines per incident and, from the Starter plan, prepares a GDPR draft; it does not submit anything.