Insights into NIS2 compliance

NIS2 requires companies to identify their critical dependencies on IT systems and recognize the associated risks. These risks must be controlled to an acceptable level, so that one can with a clean conscience look another adult, possibly an external auditor, in the eye and state that "we believe that we have now done enough." Additionally, risk mitigation controls (i.e. means that we’ve selected to handle the situation) must take into consideration modern threat landscapes, leverage “state-of-the-art technology”, follow industry best practices and include suppliers.

The directive or upcoming Finnish cyber security law does not actually define it much more thoroughly than that. All detailed guidelines, NIS2 requirement lists, or various procurement and purchasing recommendations that you might run into are merely academic guesses or suggestions that may or may not meet your own needs. Many encountered guidelines do offer well-thought-out advice and tips, though. However, it is always essential to reflect them against one's own business and critical NIS2 functions.

What is our role in society, and why are we part of NIS2? What aspects of our service or product availability does the surrounding society rely on? Which IT systems does our internal operation depend on to produce these services and products? What threats, risks, and dangers do we identify concerning these IT systems?

From this thought exercise, we can form our own list, our NIS2 requirements.

With what can external specialists then help you with?

Industry professionals can facilitate risk identification workshops helping you to map out risks related to your operations. They know industry best practices, are familiar with the latest technical safeguards and attacker tactics. They can enrich the discussion around the topic and, at best, suggest alternative approaches to identified places of mitigation. For example, a small change in operations, system architecture or application logic might eliminate a threat that one might initially consider addressing by spending money on new cybersecurity technologies. They can test your controls and protections, so that you can rely on them in real life.

Interestingly, even if the above-mentioned exercise of identifying one's own risks is done from scratch, the resulting list of mitigations and controls is often 80% the same as in a pre-written NIS2 control lists that you found from the internet. How come? There is a simple explanation - Old School IT. Everything boils down to the fact that all the world's IT runs on Linux, Windows, Unix, and Mainframes, roughly speaking.

Regardless of what type of information is handled or what industrial process is controlled using these computers, their security is always built from the same basic building blocks. Install security updates, manage admin rights, collect logs and so forth. And yes, even containers or serverless lambdas have these same fundamentals to think of. ??

Security of any IT system cannot be fundamentally built in many different ways. This is why the outcome of any risk-based or more prescriptive cybersecurity standard or regulation is, in varying tones of enforcement, to manage basic IT hygiene well and finally to take care of the basic cyber security tasks that have been discussed for decades.

This is both a relief and disturbance – We all know what needs to be done, it has just been seen that we people sometimes need a regulation and a friendly push on the back to get this ball rolling.

Main point being, the core of the NIS2 (or DORA or CER or CRA) is not about ticking all the boxes in some golden excel sheet, but to really know your own operations. Own processes and risks. Being prepared to face the modern threats and to feel pride in fulfilling the promise that you’ve made to the society around you.

We can help you all the way.