New requirements related to the National Cybersecurity System Act (KSC) and NIS2 should not result in documentation alone. In this article, experts explain how to approach asset inventory, risk analysis, the role of management, suppliers and technology so that compliance translates into genuine business security.

The discussion features:

• Tomasz Gładkowski, Management Board Representative for Cybersecurity at KIGC and COO at 4Prime IT Security;

• Dariusz Czerniawski, cybersecurity and governance expert at KIGC, CISO at Nordasys and board member of the ISACA Warsaw Chapter;

• Jakub Betka, cybersecurity and information security expert at KIGC, co-founder of CyberHabit, a company specialising in building cyber-resilient organisations, and President of the Polish Association for Personal Data Protection in the Healthcare Sector.

TL;DR

Compliance with KSC and NIS2 should not end with documentation. Genuine cybersecurity begins with an asset inventory, risk analysis and an understanding of business processes. Only then can an organisation select appropriate technical measures, establish clear accountability, address supplier security and measure the effectiveness of the controls it has implemented. Management involvement, the right expertise and treating security as an ongoing process rather than a one-off compliance project are essential.

KSC and NIS2: compliance or genuine resilience?

“A cyberattack is not an abstract problem for the IT department. It can stop production, prevent access to data, lead to contractual penalties, cause a loss of revenue and generate other financial costs for the organisation.”

Tomasz Gładkowski: A great many interpretations and recommendations have emerged around NIS2 and KSC. On the one hand, this is positive because the subject has made its way onto management board agendas. On the other hand, I have the impression that this knowledge is not always consistent and, above all, does not always reflect practical implementation experience. Companies often know what obligations they need to fulfil, but have no idea how to do it or where to begin. I would therefore like us to approach this discussion from a practical perspective and explain what organisations should do, how they should do it and what they should avoid so that KSC and NIS2 genuinely improve their cyber resilience. Because they can do that, can’t they?

Dariusz Czerniawski: They can, but only on one condition: that we do not treat these regulations solely as a compliance exercise. If our objective is simply to produce documents, procedures and signatures, very little will change. Organisations will become frustrated by another obligation, but their resilience will not improve.

NIS2 does not reinvent the wheel. It primarily organises good practices that have existed in cybersecurity for years. If an organisation treats these requirements as an incentive to launch a genuine security programme, the results can be very tangible: fewer disruptions, a lower risk of data breaches, faster incident response and greater readiness for crisis situations.

Jakub Betka: I agree. The greatest risk is that companies will reduce NIS2 to compliance and view the new obligations mainly through the lens of potential penalties rather than the real consequences of an attack. A cyberattack is not an abstract problem for the IT department. First and foremost, it is a business problem. It can stop production, prevent access to data or cause its loss, lead to contractual penalties, result in lost revenue and generate other financial costs for the organisation.

Tomasz Gładkowski: The most important point is that we implement basic security hygiene so that the business can operate more reliably. It helps organisations avoid the dramatic situations that we, as practitioners, observe following ransomware attacks and other incidents. Such situations are often extremely difficult to bring under control, particularly when the organisation does not have the appropriate security technologies or an incident response process.

Dariusz Czerniawski: There is also the geopolitical context. We are in Central Europe, between Germany and Russia, with a conventional war taking place beyond our eastern border. We have become accustomed to this fact, but not everyone realises that a cyberwar is also being waged in Poland.

We are a frontline country and a strategic support base for Ukraine. This means that we will be tested. Naturally, the average organisation does not have a budget comparable to that of a state conducting offensive operations in cyberspace. However, alongside the most sophisticated threat actors, there are many less advanced adversaries. Organisations can defend themselves effectively against them by implementing fundamental security practices.

Where should you begin? Asset inventory and risk analysis

Tomasz Gładkowski: Business owners are hearing a great deal today: KSC, NIS2, risk analysis, audits, suppliers, technical and organisational measures… It can feel overwhelming. What should be the first step towards meeting the requirements?

Dariusz Czerniawski: The first thing to understand is that security is not a fixed state. It is not the case that we achieve compliance with the legislation, close the project and remain secure. Security is a process. KSC requires organisations to launch a security programme, not carry out a one-off activity.

The first step should be an asset inventory. If we do not know what we have, which assets we are protecting, which processes are critical and what the organisation’s operations depend on, we cannot manage security effectively. A single unpatched computer can be enough for a serious incident to occur.

Jakub Betka: This is extremely important because I often see organisations doing things in the reverse order. They begin a risk analysis before conducting a proper asset inventory. They start building a risk register without knowing exactly what they need to protect. NIS2 concerns the protection of processes used to deliver services. Without an understanding of processes, assets and dependencies, the risk analysis will be incomplete.

Dariusz Czerniawski: So the asset inventory comes first, followed by the risk analysis. Only then can the organisation identify what is missing: technology, people, processes or expertise. An audit is also important, but it should not be the first moment when the organisation begins thinking about security. It is better to do the internal work first and treat the audit as a mechanism for verifying whether the organisation is moving in the right direction.

“An audit is also important, but it should not be the first moment when the organisation begins thinking about security. It is better to do the internal work first and treat the audit as a mechanism for verifying whether the organisation is moving in the right direction.”

Tomasz Gładkowski: From my perspective, there is another frequent mistake: the organisation’s first instinct is to purchase a tool because “something needs to be done”. However, technology should be appropriate to the organisation’s needs and scale. Infrastructure investments should be based on an earlier risk analysis. Otherwise, the organisation may spend a great deal of money on a solution that does not address its actual problems.

Jakub Betka: Exactly, and that is when cybersecurity begins to be seen as a cost rather than an investment. A properly conducted risk analysis makes it possible to spend money more intelligently. The objective is not to purchase every tool available on the market. It is to reduce the most significant risks to a level that the business can accept.

When we look at the consequences of an attack from a broader perspective than administrative penalties alone, the calculation changes. Consider a manufacturing company. A production stoppage does not only mean a loss of revenue. The organisation still needs to pay salaries, meet its obligations and account for contractual penalties imposed by customers for missed deadlines. Once all these factors are considered, an investment in security looks very different.

Dariusz Czerniawski: I agree. Purchasing technology alone does not solve the problem. We have seen extremely expensive systems that were not being used. Formally, the organisation could say: we have the system, we purchased it and it has been implemented. But when we asked whether anyone logged in and analysed the alerts, that was where the problem began. Security requires technology, but it also requires people and processes.

From writing policies to implementing them in practice: what challenges can organisations encounter?

Tomasz Gładkowski: Let us stay with this subject for a moment. We have established that the first step in building an organisation’s cyber-resilience framework should be an asset inventory. But what comes next? In my experience, organisations frequently ask whether they should write their policies themselves or outsource the work.

Jakub Betka: Naturally, many companies offer services in this area. An external expert can help organise the process, identify gaps and translate technical risk into business language. However, they cannot write a meaningful policy without understanding how the company actually operates. The documentation must reflect the processes, responsibilities and risks of the specific organisation. This is why the organisation must be fully involved to ensure that the policies are appropriate to its needs. The documentation should help people maintain security rather than exist solely for the purpose of an inspection.

Tomasz Gładkowski: So we do not believe in producing NIS2 documentation “within a week”?

Jakub Betka: I would be very cautious about such promises. First, you need to determine the organisation’s level of maturity, the processes it carries out, its risks, suppliers, dependencies and existing safeguards. Only then can these elements be described properly. Even in mature organisations, however, one week is far too short to make even relatively minor adjustments to security policies.

Dariusz Czerniawski: Even well-written documentation is only half the journey. It must be implemented, employees must be trained and compliance with the rules must be monitored. Security is part of organisational culture, not merely a set of procedures. Some companies genuinely care about security because it is embedded in their culture. Others believe that appointing someone responsible for security means the issue has been resolved.

Tomasz Gładkowski: The management board plays an enormous role here. In my experience, it is extremely difficult to carry out a successful implementation without both formal and practical management involvement. Meetings are cancelled, the wrong people attend, decisions are not made and consultants are unable to obtain the information they need to document the organisation’s processes.

Jakub Betka: Exactly. If the management board does not actively support the project, people further down the organisational structure will be even less likely to become involved. Conversely, when the board participates in key decisions, communicates the importance of the project and understands the business risk itself, employees can see that the subject matters. This increases the likelihood that the system will not only be implemented but also maintained afterwards.

Dariusz Czerniawski: That is what leadership means. Security standards also assess whether the management board is genuinely involved or has simply appointed a representative and considered the matter closed.

Tomasz Gładkowski: In your experience, how long does an honest implementation actually take? I do not mean writing the documents alone, but establishing an information security management system.

Dariusz Czerniawski: Realistically, around a year. Naturally, this depends on the size of the organisation and the level of involvement, but we need to remember that the process involves more than writing policies. They must be implemented, tested, measured and monitored. If the objective is to cover 100% of remote access with MFA, the organisation must subsequently verify whether that objective has actually been achieved.

Jakub Betka: My own experience also suggests that approximately one year is a realistic timeframe. Some things can of course be completed more quickly, but the question is whether the result will be a genuine implementation or merely documentation.

Tomasz Gładkowski: This brings us to an important issue: documentation needs to exist, but documents do not protect an organisation. Policies may also fail to address real risk scenarios. If the risk analysis does not account for the loss of a data storage device or the use of weak passwords, the policy itself provides a false sense of security.

Dariusz Czerniawski: Yes. A false sense of security can be worse than knowing that a problem exists. If we know we are exposed, we can take action. If we believe we are secure because we have documentation, we may overlook genuine threats.

Jakub Betka: This is why the risk analysis must be grounded in the organisation’s reality. We may have a standard, a certificate or a complete set of procedures, but if the documentation does not reflect real processes and threats, it will not be effective. At best, it may help during a formal review. At worst, it may even hinder the response to a real incident.

“A false sense of security can be worse than knowing that a problem exists. If we know we are exposed, we can take action. If we believe we are secure because we have documentation, we may overlook genuine threats.”

Expertise, accountability and the role of a Virtual CISO

Tomasz Gładkowski: Creating and following security policies is therefore not straightforward. This leads us to another problem: expertise. Who should be responsible for this within the organisation? We frequently see management boards say: NIS2 is coming into force, so we will assign it to IT. But are IT and security really the same function?

Dariusz Czerniawski: Not entirely. The head of IT has different priorities from the head of security. Security will push for system patching, updates and maintenance windows, while IT is responsible for business continuity, which the business does not like to interrupt. When a zero-day vulnerability appears, the security team’s role is to stop the relevant processes and update the vulnerable system. This usually means an interruption to production, which the business is generally unwilling to accept.

These functions naturally experience tension in every organisation. It is worth emphasising, however, that this can be healthy tension which helps the organisation maintain a high level of cyber resilience. A much greater problem arises when vulnerability remediation is postponed indefinitely for business reasons. This is why the IT and security roles should remain separate, as ISO 27001 also clearly indicates.

“The head of IT has different priorities from the head of security. Security will push for system patching, updates and maintenance windows, while IT is responsible for business continuity, which the business does not like to interrupt.”

Dariusz Czerniawski: Another common mistake involves less obvious promotions. The business selects its best engineer and says: from today, you will be responsible for security. This person may have an excellent understanding of technology, but that does not necessarily mean that they understand the business risks the organisation needs to address.

Tomasz Gładkowski: If simply assigning the subject to IT is not enough, while smaller organisations cannot realistically be expected to establish dedicated security teams responsible for implementing these standards and procedures, could a Virtual CISO provide the answer?

Dariusz Czerniawski: For many companies, yes, but the role needs to be properly understood. A consultant arrives, conducts an audit or review, leaves a report and departs. A Virtual CISO, by contrast, should maintain an ongoing presence within the organisation. They should understand its context and processes and be able to translate the language of technology into the language of business risk.

A well-designed Virtual CISO service should not depend on one individual. Mature models ensure continuity through roles such as a lead CISO and an assisting CISO. The type of support must also be tailored to the organisation. A company without industrial automation does not require the same expertise as an organisation operating an OT environment. Matching a person with the right specialist knowledge to the organisation’s business profile is therefore essential.

Tomasz Gładkowski: From a business perspective, this may indeed be more rational than employing a full-time expert. An experienced CISO represents a significant expense. In a smaller organisation, they may organise the relevant processes within a few months, but it can later become difficult to provide them with sufficiently challenging full-time responsibilities. An external model allows the organisation to benefit from people who have worked across many environments and can identify common mistakes more quickly.

Jakub Betka: Yes, but once again, a Virtual CISO should not be treated as someone who will “take care of everything” without the organisation’s involvement. They can lead, advise, organise, explain risk and support implementation. However, security must become embedded in the organisation. Otherwise, once the project ends, everything will return to its previous state.

Supply chain and documentation consistency

Tomasz Gładkowski: Since we are discussing asset inventories, documentation and accountability for security, we cannot overlook the supply chain. This is one of the areas that NIS2 emphasises particularly strongly. Organisations frequently focus on their own systems while forgetting about suppliers.

Jakub Betka: Supply chain security is indeed one of the most important subjects. Companies very often limit their attention to their own infrastructure and safeguards. NIS2, however, requires a broader perspective that includes contractors and ICT suppliers supporting the organisation’s operations.

The problem is that supplier oversight frequently ends with a general contractual clause or a questionnaire sent at the beginning of the relationship. The issue is then forgotten. Yet the security of a supplier can have a direct impact on the continuity of our own organisation.

Tomasz Gładkowski: This also represents an enormous practical challenge. An organisation may have hundreds of suppliers. Some of them are global companies over which the organisation has no meaningful influence. However, this does not remove the obligation to inventory and classify them. Organisations need to know which suppliers are critical, which services they support, which data they process and what impact a problem affecting them would have on the business.

Dariusz Czerniawski: The principle is similar to asset management. Organisations need policies for managing assets and suppliers, with a classification into important, less important and critical elements. Not everything carries the same level of risk. But to assess that risk, the organisation first needs a complete picture.

“Supply chain security is one of the most important subjects. Companies very often limit their attention to their own infrastructure and safeguards. NIS2, however, requires a broader perspective that includes contractors and ICT suppliers supporting the organisation’s operations.”

Jakub Betka: Some aspects of oversight can be automated, but for many organisations this will be a new responsibility. It was not previously included in budgets or the day-to-day work of legal, IT or security teams. There are some similarities here to GDPR and data processing agreements. In theory, oversight of data processors should be continuous. In practice, it often ends with the documents signed at the beginning of the relationship. Under NIS2, this subject will become even more significant.

Tomasz Gładkowski: Since we are discussing GDPR, I am frequently asked whether NIS2 and GDPR documentation should be separate. In my view, there is no point in creating unnecessary duplication. Some documents will relate specifically to personal data protection, but much of the risk analysis, security policies and technical procedures can be shared.

Dariusz Czerniawski: I agree. Rather than becoming attached to a single piece of legislation, it is better to understand the controls it requires and then incorporate them into the security management system.

Tomasz Gładkowski: Documentation also needs to be consistent. If an organisation creates entirely separate sets of documents for GDPR, NIS2 and other requirements, employees will find it increasingly difficult to navigate them. Documentation needs to work in practice. It must be useful.

Appropriate security measures: technology must be driven by risk

Tomasz Gładkowski: Once an organisation understands its assets, risks and processes and knows how to organise its documentation, another question arises: which security measures are actually appropriate? The word “appropriate” appears frequently in the context of NIS2 and KSC, but it can be interpreted in many different ways. What does appropriate really mean?

Dariusz Czerniawski: Appropriate to the risk. That is the key point. The risk analysis should indicate which measures are necessary, which are proportionate and which would be excessive. In cybersecurity, we frequently calculate the cost of implementation, but it is more difficult to calculate the return on investment because it usually consists of losses that have been avoided. If safeguards help prevent a disruption, a data breach or a contractual penalty, that is where the value lies.

Tomasz Gładkowski: As a security systems integrator, I see a major problem in the market. Some organisations purchase a SIEM, an event correlation system, even though they have not yet deployed EDR on their endpoints and servers. A SIEM can be an excellent tool, provided that the organisation understands why it is implementing it, has the necessary data sources, correlation rules, an alert handling process and people who will work with the system.

We should also remember that a SIEM does not stop an attack. It only identifies events that have previously been described through correlation rules. Given the way SIEM systems operate and their inherent limitations, EDR and NDR solutions play a particularly important role today. They provide effective, comprehensive detection without requiring organisations to define and maintain hundreds of correlation rules. EDR is closest to the people and data we are protecting. Incidents are also very often connected to human behaviour: an employee clicks a link, opens an attachment, runs a file or simply makes a mistake.

“In cybersecurity, we frequently calculate the cost of implementation, but it is more difficult to calculate the return on investment because it usually consists of losses that have been avoided. If safeguards help prevent a disruption, a data breach or a contractual penalty, that is where the value lies.”

Dariusz Czerniawski: Exactly. An alert without a response provides little value. We may know that a problem exists, but if nobody knows what to do next, we do not have security. We simply have another source of noise.

“An alert without a response provides little value. We may know that a problem exists, but if nobody knows what to do next, we do not have security. We simply have another source of noise.”

How can organisations measure the effectiveness of implemented safeguards?

Tomasz Gładkowski: How, then, should organisations measure whether all of this is working properly? If security is a process, we need a way to assess progress.

Dariusz Czerniawski: The best approach is to measure progress against specific objectives. Every security measure is implemented for a reason. If the objective is to achieve 100% MFA coverage for remote access, we measure whether it has been achieved. If the objective is to respond to an alert within a specified period, we measure the time between the notification and the first response action. The organisation needs to answer one question: how will we know that a particular control is working?

Tomasz Gładkowski: Organisations can also use Attack Surface Management tools, which provide an external view of the services exposed to the Internet, identify where MFA or 2FA is missing and highlight vulnerabilities. By comparing the results over time, the organisation can determine whether its security posture is improving or remaining unchanged.

Jakub Betka: The important point is that the metrics should not be artificial. They should indicate whether the organisation is genuinely reducing risk, not merely completing spreadsheets. If we measure the number of training sessions conducted, we should also verify whether user behaviour has changed. If we measure incident response times, we need to know whether the procedure actually worked in practice.

Can KSC genuinely improve cybersecurity in Poland?

Tomasz Gładkowski: This brings us to the key question: can KSC genuinely become a game changer for cybersecurity in Poland?

Jakub Betka: It can, provided that organisations approach the subject from the perspective of security rather than compliance alone. The objective is for the sectors covered by the directive to genuinely ensure cybersecurity and network security. An attack on one sector should not cause disruptions or consequences in other sectors. In my view, NIS2 can significantly improve the cybersecurity of the entire country if all the sectors it covers approach the requirements properly.

Dariusz Czerniawski: If compliance is the objective, we will end up with documents. If the objective is to secure the business and, as a result, strengthen the resilience of the entire country, KSC and NIS2 make sense.

Tomasz Gładkowski: I also believe that KSC is a common-sense framework. Every organisation can implement it to an extent that genuinely improves its cyber resilience and business security. It is also important not to wait until the last minute. This cannot be done quickly or through documentation alone. Security is a process that requires management involvement, expertise, investment and consistency. If organisations approach it honestly, it will cease to be viewed solely as a cost and will begin to genuinely strengthen the business.

To find out whether your company is ready for NIS2, download our checklist.

This article is based on the transcript of the webinar Can KSC Genuinely Improve Cybersecurity in Poland? An Expert Discussion.