GDPR vs NIS2: what your company actually has to do

A compromised Microsoft 365 account, an invoice email sent by a criminal or an encrypted server can become an operational problem, a security problem and a data protection problem all at once. That is why the question “GDPR vs NIS2” should not lead to choosing between the two. What matters for a business is understanding which obligations apply to it, and whether it can detect and contain an incident before it turns into downtime, a data leak or a financial loss.

The GDPR and NIS2 have different aims, different scope and different regulatory language. In practice, though, they share the same IT environment: user accounts, email, servers, employee devices, cloud systems and suppliers. A misconfiguration or an unauthorised login can touch both areas at the same time.

GDPR vs NIS2 – the key difference

The GDPR is about protecting personal data. It governs how an organisation collects, uses, stores and secures data relating to individuals – a customer list, employee records, accounting documentation, correspondence history, job applicants’ details. It applies to a wide range of controllers and processors.

NIS2 is the EU directive on cybersecurity and the resilience of entities operating in sectors classed as essential or important. Its requirements are transposed into national law. Whether a particular organisation falls within scope depends on the sector, its size, the nature of its activity and the national legislation that applies. That assessment should reflect the law as it currently stands and the company’s real role in the chain of services.

The simplest way to put it: the GDPR asks whether personal data is processed lawfully and protected appropriately. NIS2 asks whether the organisation manages cyber risk and can keep operating and respond to serious incidents.

That distinction does not mean the two areas work separately. A ransomware attack on an HR system can reduce the availability of services, breach the confidentiality of employee data and demand a well-run incident process. A single technical event can therefore trigger parallel business, organisational and regulatory obligations.

Different scope, shared business risk

The GDPR focuses on the people the data relates to. An organisation should limit the scope of the data it processes, control access, set retention periods and apply technical and organisational measures proportionate to the risk. This is not about deploying one tool – it is about managing data deliberately across its whole lifecycle.

NIS2 puts more weight on the security of systems and networks. In practice that means risk management, incident handling, business continuity, supplier control, access protection and building staff awareness. What counts is not whether a company has a policy, but whether it can apply it during a real attack.

For management, the common denominator is reducing business risk. A leak of customer data can damage trust and create operational cost. An unavailable production, warehouse or accounting system can stop the company working. A compromised mailbox can be used to commit invoice fraud or extract a payment.

Confidentiality, integrity and availability

The GDPR is most often associated with confidentiality – protection against unauthorised access. That is important, but it is an incomplete view of cybersecurity. Integrity matters just as much: confidence that data or configurations have not been altered by someone without authorisation. So does availability: being able to use systems when they are needed.

NIS2 strengthens the continuity perspective explicitly. A company may lose no personal data at all and still suffer badly if an attack prevents it fulfilling orders, serving customers or reaching its documentation. Good controls should therefore protect both the data and the organisation’s ability to work.

Reporting an incident does not start with a form

Under the GDPR, a personal data breach has to be assessed for the risk it poses to the rights and freedoms of individuals. In defined situations it must be notified to the supervisory authority, as a rule within 72 hours of becoming aware of it. Not every technical event is automatically a notifiable breach, but every such decision requires documented analysis.

Under NIS2 there is a framework for reporting significant incidents, including an early warning and later notifications. The detailed obligations, deadlines and reporting channels should always be verified against the legislation that applies to the specific entity. It is not worth waiting for a formal obligation before putting a response process in order.

The bigger problem usually appears earlier: the company does not know when the incident happened, how far it reaches or which systems were affected. Without logs, event analysis and a defined split of responsibility, it is hard to produce a credible assessment in a short time.

The example is simple. An employee reports unusual mailbox behaviour. Is it a single phishing message, or a compromised account with rules forwarding correspondence to an external address? Did the attacker sign in from an unusual location? Did they download files from the cloud? Answering that takes technical data and fast analysis, not just a procedure filed in a binder.

How to prepare without over-building

The scale of the controls should match the size of the organisation, its services, the value of its information and the threats it realistically faces. A small company does not have to copy a large institution’s security model. It does have to be able to name its key systems, the people responsible, its main risks and how it will act when an incident occurs.

Access is a good starting point. Administrative accounts should be separated from ordinary user accounts, and multi-factor authentication should protect email, cloud systems, remote access and other critical services. Removing permissions promptly when someone changes role or leaves matters just as much.

The next area is patching, backups and recovery. A backup that has never been tested is not evidence of continuity. A company should know which systems to restore first, where the copies are held and who makes the decisions in a crisis.

Training matched to the risks is needed too. An employee does not have to know the technical names of attacks, but should recognise a suspicious payment request, a fake login page and unusual account behaviour. Whoever owns the finance process should have an extra procedure for confirming changes to a supplier’s bank details.

Monitoring as both evidence and response time

Policies and preventive controls are necessary, but they do not stop every attack. That is why detecting threats after they occur matters. Continuous security monitoring surfaces signals a single administrator can miss: a run of failed logins, a sign-in from an unusual country, protection switched off on a workstation, a suspicious program launch, or mass file encryption.

24/7 monitoring is not simply the collection of alerts. In a SOC as a Service model, analysts judge which events are genuine threats and which only call for a configuration fix. MDR – Managed Detection and Response combines detection with incident handling and response. The aim is to shorten the time from the first signal to a concrete action.

Depending on the environment, monitoring can cover computers, servers, firewalls, Microsoft 365, Google Workspace and cloud resources. Central log collection in a SIEM makes it easier to reconstruct what happened: who signed in, what they did, which data they reached and whether other systems were affected.

That has a regulatory dimension, but above all a practical one. When a breach is suspected, a company needs facts. Without them it is hard to cut off the attacker’s access, make the right communication decision, judge the scope of the event and restore safe operation.

GDPR and NIS2 as one risk-management programme

Separating responsibility for personal data from responsibility for IT is a common source of gaps. The person handling data protection may not hear about an incident in time, and the administrator may not know which systems hold particularly sensitive data. It is worth bringing those perspectives into one practical process.

That process should define which systems are critical, where personal data is processed, which events require escalation and who decides. It should also involve regularly checking that access rights, backups, configurations and procedures work as intended. A security audit, penetration testing, vCISO support and continuous monitoring each play a different role, but together they help build measurable resilience.

The best first step is not buying a tool at random. It is an honest answer to one question: would the company notice an account takeover or ransomware quickly enough to limit the damage? If the answer is “we don’t know”, start by identifying the key risks and establishing a workable way to monitor them. If you would like help with that, talk to our team.

Chief Technology Officer (CTO). For security reasons we do not publish authors’ names – articles are signed by role only, without details identifying a specific person.