The NIS2 Directive takes this into account. As a result, NIS2 also raises the bar for cyber security and risk management within organisations. It is not just an organisation’s own IT systems that play a role here. Organisations must increasingly address the risks arising from service providers, software suppliers and other elements of their supply chain.
For us at , part of EGOTEC AG, this is not a new issue. As an ISO 27001:2022-certified SaaS provider, we have established technical and organisational processes through which we continuously monitor and assess security risks.
NIS2 also takes the supply chain into account
NIS2 requires affected organisations to implement appropriate and proportionate technical, operational and organisational measures to manage their cybersecurity risks. This explicitly includes supply chain security, encompassing security-related aspects of the relationships between organisations and their direct suppliers and service providers.
This also changes the relationship between organisations and their software providers: even if a SaaS provider is not directly subject to a specific obligation, its customers may demand evidence of security compliance because they, in turn, must assess and secure their own supply chains.
For us at EGOTEC AG, this means:
Security must not only be documented at a customer’s request.
It must be an integral part of the ongoing development and operational process.
Knowing what’s in the software: SBOM
Modern software does not consist solely of in-house developed programme code. Frameworks, libraries and other components are an integral part of almost all software today. That is why it is important to know:
Which components do we use – and do they contain any known security vulnerabilities?
An important basis for this is the Software Bill of Materials (SBOM). Put simply, you can think of it as a bill of materials for a piece of software.
At SaaS.de, we don’t just have one such bill of materials. We create SBOMs for different parts of our software – for example, the front-end, back-end and modules. This makes it possible to trace which software components form part of our applications.
From the bill of materials to continuous risk analysis
An SBOM on its own does not make software secure. What matters is what happens with this information afterwards.
Our SBOMs are therefore automatically transferred to OWASP Dependency-Track. There, the components used are continuously cross-referenced against known vulnerabilities and assessed for risk.
In this way, a simple list of components is transformed into an active tool for our vulnerability management. If new security vulnerabilities in a component we use come to light, this information is incorporated into the risk assessment – even if nothing has changed in our own software since the last build.
Clear thresholds rather than a false sense of security
‘We pay attention to security’ is not enough for us. As part of our ISO 27001:2022-certified information security management system, we have therefore set specific thresholds for the identified risks. The risk scores are reviewed regularly, at least every two weeks.
This creates a transparent process:
Identify software components → Detect vulnerabilities → Assess risks → Check thresholds → Implement necessary measures
Security management thus becomes measurable and reproducible.
ISO 27001 and NIS2: Security as a process
NIS2 clearly demonstrates the direction in which requirements for organisations are evolving: cybersecurity must not be a one-off technical measure. What is needed are ongoing processes for risk management, vulnerabilities, incidents and supply chains. This is precisely where an established information security management system comes into its own. Our certification to ISO 27001:2022 does not simply mean that an audit took place at a specific point in time. It stands for defined processes, responsibilities, controls and the continuous improvement of information security.
The technical analysis of our software components forms an integral part of this overall system.
Security from the outset
One principle is particularly important to us:
Security should not only become an issue when a customer requests proof.
Anyone who only starts to find out, upon a customer enquiry, which components are used in their software and which known vulnerabilities exist within it is taking a reactive approach to security. At SaaS.de, monitoring the software components in use is an integral part of our established security processes.
This not only makes it easier to meet increasing regulatory and contractual requirements. Above all, it helps to identify risks at an early stage and to protect our customers’ data in the long term.
SaaS.de: Simple. Secure. Online.
With NIS2, the Cyber Resilience Act and increasing demands on software supply chains, traceable IT security is becoming ever more important.
For SaaS.de, this is not a project that was only initiated in response to new legal requirements.
SBOMs, automated vulnerability analyses, defined risk thresholds and regular checks are already an integral part of our security management.
After all, companies that entrust their HR processes to SaaS.de should be able to rely on the fact that, for us, security is not just a promise, but something we systematically put into practice.
We’d be happy to discuss this topic on LinkedIn.