GDPR and NIS-2: What Companies Need to Know About Software Security

Two Sets of Rules, One Goal

When it comes to software security, two terms come up especially often in Germany and the EU: the General Data Protection Regulation (GDPR) and the NIS-2 directive. Both ultimately pursue the same goal, namely that data and IT systems are handled responsibly. They just do so from different angles.

This article gives a practical overview, not a legal opinion. When in doubt, and for concrete obligations, you should consult legal advice. The aim here is to help you, as the responsible party, ask the right questions.

GDPR: the Basics for Custom Software

GDPR governs how personal data may be processed. As soon as your software processes data about identifiable people, you are within its scope. Three points are particularly relevant for custom software:

• Data minimisation: collect and store only what you genuinely need. Every field you do not capture is a field you do not have to protect or delete.
• Data processing: as soon as a service provider processes data on your behalf, such as a hoster or an email sender, you need a data processing agreement that sets out duties and limits.
• Hosting in the EU: a location inside the EU avoids a large part of the complexity around transfers to third countries. It is often the simplest way to stay on the safe side.

Good software supports these principles by design: clear deletion concepts, separated access rights and lean data models are not an afterthought but part of a clean design.

NIS-2: a Much Broader Scope

NIS-2 is the revised EU directive on cybersecurity. The most important difference from its predecessor is the broadened scope. It no longer affects only classic operators of critical infrastructure, but considerably more companies, including small and mid-sized ones, across a whole range of sectors.

For affected companies, NIS-2 mainly brings two kinds of duties:

1. Security measures: appropriate risk management for IT, from access control through encryption to contingency plans.
2. Reporting duties: significant security incidents must be reported to the relevant authorities within set deadlines.

Whether and to what extent your company is affected depends on sector and size. That classification is exactly where a professional assessment pays off. Even if you do not fall directly under NIS-2, as a supplier you may be indirectly affected, because your clients ask for evidence.

Practical Security Hygiene

Regardless of which set of rules applies to you, a handful of measures make almost any application safer. They are less spectacular than their names suggest, but they work:

• Updates: keep dependencies and systems current so that known holes do not stay open.
• Least privilege: every account gets only the rights it truly needs. A compromised account then does less damage.
• Backups: regular and tested backups, ideally also outside the production system.
• Logging: traceable logs so that in an emergency you can see what happened and can meet reporting duties at all.

These four points are not optional extras but the foundation. Implement them consistently and you cover a large part of what both GDPR and NIS-2 require at their core. What matters is that the measures are not just set up once but kept alive over time. A backup that has not been tested in months, or logs that nobody ever looks at, only give a false sense of security.

It also helps to decide early who does what in an emergency. A short, written response plan for security incidents saves valuable time in the acute moment and makes sure reporting deadlines are met rather than lost in the rush.

For smaller organizations, this does not have to become an oversized security programme. A pragmatic start is often enough: clear responsibility, an update rhythm, tested backups, monitoring and a short incident plan. What matters is that these points are actually operated, not just written into a concept once.

Security Is a Process

The most important thought to close on: software security is not a state you reach once and then tick off. It is an ongoing process of updates, review and adjustment. This is exactly where maintenance and security interlock, because without regular care every measure stays just a snapshot.

As a reminder: this is practical guidance, not legal advice. If you would like to know how your software stands in relation to these requirements, feel free to get in touch. We will look together at where your system is solid and where it makes sense to improve.