NIS2 for Smaller Organizations #1 – Program Management Made Simple

What does Program Management mean?

The term may sound rather corporate, but the idea behind it is simple.

An organization must know what it is protecting, what it is protecting it against, who is responsible, what problems exist, what it is doing to resolve them, and how it knows that its measures actually work.

The Program Management requirements therefore cover, among other things, the information security policy, the role of the information security officer (IBF), necessary resources, the register of electronic information systems, risks, measurement of security performance, reviews, suppliers and continuous monitoring. The decree’s risk management framework also requires organizations to document security roles, their risk management strategy and the continuous evaluation of the effectiveness of safeguards. Legal reference (Jogtár)

Above all, this is a matter of governance; technology comes second.

Consider an organization with eight employees

Let us take a simple example.

There are eight employees, eight to ten computers, a NAS, a router or firewall, an internet connection, some form of cloud email, a few external services and an outsourced system administrator. There is no separate IT department and no information security team. Even the IBF function may be performed by an external provider.

Building an enterprise-grade governance, risk and compliance (GRC) platform for this environment is not realistic. Security still needs to be managed, however.

As a starting point, we would organize the Program Management requirements for an organization like this around the following seven functioning elements:

Of course, this does not mean that all the decree’s requirements are automatically “ticked off”. It means organizing numerous individual requirements into a framework that a small organization can genuinely operate.

You do not need a separate policy for everything

This is one of the most common misunderstandings.

Section 1.1 of Decree 7/2024 MK, for example, sets out detailed requirements for the information security policy: it must cover security requirements and safeguards, define objectives, roles and responsibilities, among other things, and receive management approval. But that does not mean another twenty-page policy must be written for every subsequent requirement. For a smaller organization, a well-structured, unified information security policy (IBSZ), supported by a handful of short procedures and registers, may make far more sense. The goal is not to increase the number of documents.

The goal is to ensure that what is written down actually works in practice.

Do we even know what we are protecting?

This is one of the most important questions.

It is extremely difficult to manage an organization’s information security properly without a clear picture of the electronic information systems it uses. In a small municipality, for example, even defining the boundaries of those systems is not always straightforward.

What belongs together? Is the file server a separate system? What about the NAS, email, the financial system, access control or cloud services?

The decree’s risk management framework requires, among other things, the documentation of the business purposes, functions, assets, technological boundaries, processed data and risks of affected systems.

So the first practical step is not necessarily to install new software.

It is much more likely to be creating a usable register of electronic information systems (EIR).

For a small organization, a properly designed spreadsheet can be perfectly suitable for this.

Problems must also be tracked

During compliance work, we will almost certainly discover shortcomings.

These may include an outdated operating system, inadequate backups, too many administrator privileges, missing multifactor authentication (MFA), or undocumented supplier access. The real problem is not discovering a gap. It is having nobody who knows what happens to it next.

That is why an action plan is needed.

Even a simple table may be enough to record:

finding → required action → owner → deadline → status.

At that point, security stops being a policy taken off the shelf once a year and becomes a managed process.

How do we measure security in a small organization?

One interesting Program Management requirement is the measurement of security performance.

Under the decree, an organization must establish a system for measuring the security of its electronic information systems, monitor performance indicators and report on them regularly.

At first, that might sound like another enterprise dashboard.

But an organization with eight employees can start with as few as five simple indicators.

For example:

completion of critical updates · failed backups · open security actions · overdue actions · security training completion rate

These can form the basis of a one-page quarterly IBF report.

Continuous monitoring ≠ watching a screen continuously

Requirement 1.23 calls for a continuous monitoring strategy and program. This must define performance indicators, review frequencies, analysis, response actions and regular reporting.

Nor does a small organization have to overcomplicate this.

In this context, “continuous” does not necessarily mean someone watching a screen in a security operations center (SOC) around the clock.

It can mean an established review cycle: certain technical checks every month, a security status assessment each quarter, a comprehensive annual review, and an extraordinary review following a significant change or incident.

What matters is consistency and the ability to document the activity.

And what software do we need to buy?

Perhaps the most important answer in this first part is:

none – not merely to satisfy this family of requirements.

We can also use LibreOffice Calc spreadsheets.

If the organization eventually outgrows that approach, it can move to a more sophisticated system.

Not the other way around.

Do not introduce a complex system just because it exists. Introduce one when the organization’s actual operations justify it.

What will an auditor or NKI inspector see?

One of the most important questions in compliance is:

can we demonstrate that what we have written in our policy actually works?

For Program Management, a well-organized organization can support this with, among other things, a current information security policy (IBSZ), a documented IBF role, an EIR register, risk analysis, an action plan, review records, training records, supplier information and regular security reports.

Here, too, the point is not the volume of documents.

Consistency is what matters.

If a risk assessment identifies backups as a problem, that should appear in the action plan. If the action plan says the problem has been fixed, there should be evidence.

If the organization says it checks backups quarterly, there should be a record that these checks actually happened. That is what makes a system of controls auditable.

The NIS2 for Smaller Organizations principle: start simple

Decree 7/2024 MK does not establish a separate catalogue of requirements for small organizations. Smaller organizations must also take the security requirements that apply to them seriously. But that does not mean they have to meet them with exactly the same technological and organizational solutions as a company with thousands of employees. The decree itself is based on risk management: organizations must assess and treat risks affecting their systems and put suitable safeguards in place. Legal reference (Jogtár)

A small organization does not need less security. It needs security proportionate to its size and risks.

That is a major difference.

Now it is your turn

We do not want the “NIS2 for Smaller Organizations” series to be a one-way channel for professional content.

We also want to hear from system administrators, information security officers, auditors, IT specialists and affected organizations about their practical experience.

How does Program Management work in your organization? Excel, LibreOffice, SharePoint, a NAS, an in-house solution or a dedicated system?

Is there a simple approach that has worked particularly well?

Tell us under the social media post accompanying this article. We will draw on useful ideas and experiences in future installments. At the end of the series, we also hope to use them to prepare a summary guide entitled “NIS2 for Smaller Organizations – A Practical Guide”.

And why are we addressing this at CyberTeam?

Because, time and again, our practical experience shows that a good information security solution is not necessarily the most expensive or the most complicated.

First, we need to understand how the organization operates, which systems it depends on, what risks it faces and what it actually needs.

Only then does it make sense to discuss technology, new systems or additional costs.

This is also how we work at CyberTeam Kft.

Because cybersecurity is only good if it works on more than just audit day.