The days when cybersecurity could be written off as the IT department’s problem are over. Since the amended National Cybersecurity System Act (Krajowy System Cyberbezpieczeństwa – KSC), which is Poland’s transposition of the EU’s NIS2 Directive, came into effect on 3 April 2026, cyber risk management has, by necessity, landed under the direct oversight of senior management. Not least because the law now provides for personal liability. For thousands of Polish companies and organisations, the upshot is simple: cyber resilience has stopped being a buzzword in a slideshow and has become an obligation backed by concrete sanctions.
What is cyber risk management?
It’s the continuous process of identifying, analysing, evaluating and reducing risk tied to cyber threats. The goal is to protect the organisation from incidents, data loss and downtime, and, more broadly, to preserve operational continuity and customer trust. The key word is continuous: this isn’t a one-off project with a finish line and a participation trophy at the end; this is a process meant to respond to the shifting threats and changes within the organisation itself. Cyber risk management spans five areas: people, processes, technology, data and suppliers. Under the new rules, it’s the supply chain that draws the most attention.
Why does cyber risk management matter today?
In just five years, the number of cybersecurity incidents handled in Poland has climbed from around 10,000 to more than 260,000 a year. Awareness, meanwhile, lags behind: industry surveys suggest that over a third of professionals can’t say whether their company falls under NIS2 at all. That may be one of the reasons why the law has been changed – to jolt boards out of their slumber with financial penalties and personal liability. Fines for essential entities reach €10 million or 2% of turnover; for important entities it’s €7 million or 1.4%. Liability can also fall directly on management, with financial penalties of up to 300% of salary and, potentially, a ban from holding management positions. Cybersecurity has become a business risk in a far more visible way.
What does the risk management process involve?
The risk management process breaks down into five stages: identification; analysis; evaluation and prioritisation; choosing a strategy and implementing controls; and finally monitoring and continuous improvement. And then the whole cycle begins again, because a changing world keeps throwing up new threats.
Identifying threats and vulnerabilities
The first step is taking inventory of your assets: hardware, software, data, systems and accounts. After all, you can’t protect something you don’t know exists; and a forgotten server or an out-of-date application is like an unlocked door for an attacker. Worth remembering: a great many attacks are essentially probing exercises, with attackers hunting for exactly these kinds of gaps in security. With an asset map in hand, you can identify the threats (phishing, ransomware, supply-chain attacks) and the vulnerabilities they could exploit.
It pays to think through possible attack scenarios. For example: an employee clicks a link in a fake email, the attacker takes over the account, moves laterally across the network and, a few days later, encrypts the company’s data and demands a ransom. Every link in that chain – lack of training, no MFA, no segmentation, no backups – is a separate risk that could have been reduced before the incident ever happened.
Analysing and evaluating risk
Here we assess two parameters for each source of risk: likelihood and impact. The most popular tool to do this is a risk matrix. The illustration below shows an example. In short, one axis marks how likely an event is (physical access to, say, a router in a hallway is more likely than to a locked server room), and the other marks how serious the consequences would be (here, the server matters far more than the router). Where a problem lands on the matrix tells you which risks are most pressing and often hints at what to do about them. If losing your only copy of the data could sink the company, then, for heaven’s sake, make a backup. If high staff turnover raises the risk of losing key employees, it might be worth asking yourself why they keep leaving in the first place. So, yes, HR policy can be part of cybersecurity too.
The approach to the analysis itself can be qualitative or quantitative. In the first instance, a group of experts (i.e. people who understand the problem and know what they’re talking about) rate the likelihood and scale of various threats as low, medium, or high. In the second, risk is expressed numerically, based on potential financial losses. The latter is harder to do, but it does concentrate the minds of a board that thinks in numbers.
Risk appetite, risk tolerance, and prioritisation
Two terms must be distinguished here because they can easily be confused: risk appetite and risk tolerance. The former is the level of risk an organisation knowingly accepts in pursuit of its goals. The latter, in turn, is the permissible deviation from that level for a specific process or asset. So if a company tolerates risk at, say, 1% level, how much is it willing to accept for activities with unusual upside? 2%? 10%? Without defining these tolerances, prioritisation turns into guesswork, and security spending becomes hard to justify.
Once you’ve established which risks are critical, you can decide what to do about them. Traditionally, four approaches are distinguished: reduce, transfer (e.g. to an insurer), avoid, or knowingly accept. Reducing risk means putting safeguards and procedures in place to lower either the likelihood of a threat or the severity of its impact. In the earlier examples, that would mean restricting access to infrastructure, making backups, and working on staff retention. Transferring risk shifts the financial or operational responsibility to a third party, usually by buying insurance or outsourcing the process in question. Although it’s worth stressing that in cybersecurity, especially in light of the stress placed on supply chain security in NIS2, outsourcing might just be more bother than it’s worth. Avoidance means abandoning a particular activity, technology or project altogether, eliminating the associated risk outright. A timely example is the use of AI: many companies have poured money into large language models and most have gained little beyond marginal marketing value. Declining to roll out a flashy but unproven technology sidesteps such risk entirely. Finally, acceptance is a conscious decision to leave a risk as it is, typically when the cost of safeguards outweighs the potential loss, or when the potential upside is simply too great to pass up (which is presumably what drove the managers bolting AI onto every service imaginable). Given the new rules, documenting every decision is essential, and for acceptance it matters even more than for the others, because it leaves little other trace. And consciously taking on a risk after weighing costs and benefits is a whole different ball game from being exposed to it through neglect. Documentation is your evidence of due diligence if regulators come knocking.
Strategies for reducing risk
Effective risk reduction rests on technical and organisational controls, ideally layered as defence in depth, so that breaching one layer doesn’t spell catastrophe. The fortress analogy genuinely fits here (a trip to your nearest nineteenth-century piece of military architecture is highly recommended). Bear in mind, too, that tools alone won’t do, processes and people matter just as much.
Security controls and governance
In this context, governance means assigning roles, responsibilities and policies. The heart of the new approach is leadership accountability: the board must approve risk-management measures, oversee their implementation, and understand the risks it is accepting. This can no longer be dumped on the IT department alone, because (a) cyber risk is now simply too great of a threat, and (b) the law puts personal responsibility on management.
Threat monitoring and incident response
Monitoring has to be continuous, not something done once a year “for the audit.” The cyber-threat landscape is far too volatile for that. You need to track events, vulnerabilities and anomalies constantly, so you can catch a problem before it turns into a headline. The other side of the coin is incident response: an organisation should have procedures ready for detecting, isolating and eliminating a threat and restoring full functionality.
Speed is of the essence here. For a significant incident, the KSC Act requires an early warning within 24 hours, a full notification within 72 hours, and a final report within a month. Reports go to the CSIRT (Computer Security Incident Response Team) appropriate for the given organisation’s area of activity. Without procedures ready to go, meeting those deadlines verges on the impossible.
Managing supplier and supply-chain risk
This is the Achilles’ heel of many firms, since a supplier’s security problems can quickly become your own, especially when it comes to software and IT services (SaaS, cloud services, technical support). But even elsewhere, since these days optimising processes usually means some degree of systems integration. That’s why assessing and tiering suppliers, security questionnaires, contractual clauses and continuous monitoring (rather than a “trust and forget” approach) are central to staying secure. Moreover, entities within the scope of NIS2 are obliged to secure their supply chains. The knock-on effect is that even smaller firms outside the law’s scope often have to meet cybersecurity requirements as a condition of a contract with a larger, NIS2-compliant customer.
Security awareness and culture
You can spend a fortune on technology and still lose to a single careless click. That’s why building staff awareness is a fully fledged part of security control. Regular training, phishing drills, and clear response procedures can cut risk more effectively than many an expensive IT system. Crucially, NIS2 and the KSC act put particular emphasis on educating management: training for the board is now mandatory and must be documented.
Supporting technology: SIEM, SOAR, EDR, IAM, MFA
It may look like alphabet soup, but each of these acronyms stands for a worthwhile security technology. SIEM (Security Information and Event Management) collects, analyses and correlates logs and security events from across the company’s infrastructure in real time to spot anomalies and threats. SOAR (Security Orchestration, Automation and Response) is a platform for coordinating, automating and rapidly responding to security incidents without constant human intervention. EDR (Endpoint Detection and Response) monitors and protects endpoints (workstations, laptops and servers) and can detect and immediately block attacks at the device level. IAM (Identity and Access Management) governs identities and permissions, making sure the right users can reach only the resources and data they actually need. MFA (Multi-Factor Authentication) requires at least two different proofs of identity at login (for instance, a password plus a code from an app or SMS). If you implement just one of these, make it multi-factor authentication. It’s cheap, simple, and often overlooked, but it’s able to block a huge share of attacks that rely on stolen passwords. In a nutshell: SIEM collects and correlates events, SOAR automates the response, EDR protects workstations and servers, IAM manages identity and access, and MFA makes sure users really are who they say they are.
Compliance: NIS2, DORA, ISO 27001, and GDPR
In brief: NIS2 is the EU baseline, to which Poland’s KSC act adds a national administrative layer, including a high-risk-supplier mechanism, mandatory board training, and a formal register of essential and important entities. It’s also useful to know the catalogue of basic measures listed in Article 21 of NIS2: risk analysis, incident handling, business continuity and backups, supply-chain security, vulnerability management, cyber hygiene and training, cryptography, access control and asset management, and MFA. DORA (the Digital Operational Resilience Act), the EU regulation on the digital operational resilience of the financial sector, entered into force in early 2023 and, since January 2025, has imposed a dedicated cybersecurity and operational-resilience regime on financial entities. ISO/IEC 27001 is the voluntary, certifiable standard that ties these requirements into a single auditable system. GDPR functions alongside cybersecurity proper, since its aim is to protect personal data rather than systems but in practice the two goals often overlap, because personal data is held digitally and a single breach can trigger two separate reporting duties.
How to build an effective security programme, step by step
The most popular skeleton is the NIST Cybersecurity Framework 2.0, built around six functions: Govern, Identify, Protect, Detect, Respond and Recover. The newly added Govern function treats cybersecurity as a business risk and raises supply-chain risk to a category of its own. That dovetails with the logic of NIS2, which makes the framework an excellent basis for implementing compliance with the directive. In practice, the order of play might look like this:
- Establish whether the rules even apply to you (self-identification by sector and size is the rule, so nobody is sending you a notice).
- Run a gap assessment against the law’s requirements.
- Base your decisions and spending on a risk analysis, not on a shopping list of tools.
- Create an information-security management system, policies and response procedures.
- Get the board involved and trained; secure your supply chain.
- Test your procedures with a simulation. It’s the only way to know whether they work.
- Schedule regular reviews and updates.
Best practices
The key principles: risk analysis before purchasing (a common mistake is procurement not consulting IT and presenting them with a fait accompli); documented decisions (especially a conscious decision to change nothing); a trained board (remember, liability is now personal); secured suppliers (the organisation is now answerable for its supply chain); regular testing of your response; and backups. All of it should run as a continuous process, not a one-off exercise.
Common mistakes organisations make
Here are the cardinal sins. The “tick the box and forget” approach; reality shifts, the company grows, software updates, new threats emerge; cybersecurity demands constant monitoring and updating. Confusing registration with actually meeting the obligations; registering is only the first step; you still have to put security procedures in place. Buying tools before understanding the risks they are meant to address. Ignoring supply-chain risk. And the perennial problem: stalling, even though a realistic rollout takes nine to fifteen months, so companies planning to start “in a moment” are already behind.
In summary
Cybersecurity risk management is no longer a project with an end date, but a permanent, strategic-and-operational part of running an organisation. The starting point is risk analysis and self-identification under NIS2/KSC, and responsibility rests with the board, not just IT. The weakest links tend to be people and suppliers, not technology. The deadlines have already been set, so the best moment to start has passed. The second-best is now.
Key takeaways:
- Cyber risk management is a continuous process, not a one-off project.
- It all begins with risk analysis and self-identification under NIS2/KSC.
- Cybersecurity is a board-level responsibility, backed by real sanctions.
- The supply chain and staff awareness are often weaker links than IT tools.
- NIST CSF 2.0 offers a ready-made skeleton aligned with NIS2.
