{"id":6129,"date":"2026-11-01T12:13:30","date_gmt":"2026-11-01T11:13:30","guid":{"rendered":"https:\/\/www.lablogic.pl\/?p=6129"},"modified":"2026-11-01T12:42:05","modified_gmt":"2026-11-01T11:42:05","slug":"ksc-risk-assessment","status":"publish","type":"post","link":"https:\/\/www.lablogic.pl\/en\/ksc-risk-assessment\/","title":{"rendered":"How to carry out the risk assessment required by the KSC Act?"},"content":{"rendered":"\n

Micha\u0142 Rutkowski<\/strong><\/a> \u2022 for the board, CISOs and compliance \u2022 published November 1, 2026 \u2022 15 min read<\/p>\n\n\n\n

\n
\n
\n\n\n\n<\/div>\n<\/div>\n\n\n\n
\n
\n

Short answer<\/h2>\n\n\n\n

The Polish Act on the National Cybersecurity System (KSC) implements the NIS2 Directive. Under the Act, risk assessment is the overall process of identifying, analysing and evaluating risk (Article 2(13)). An essential or important entity carries it out systematically with regard to the risk of an incident occurring in the information systems used in processes that affect the provision of the service. It bases the selection of technical and organisational measures on the result of the assessment, alongside among others the cost of implementation and the size of the entity (Article 8(1)(1) and (2)). The Act does not describe the method. According to the Minister of Digital Affairs the risk assessment process should be described in the risk assessment policy, which the Act lists in the catalogue of measures (Article 8(1)(2)(a) and Q&A 3.3).<\/p>\n\n\n\n

The process template is provided by point 2.1 of the Annex to Commission Implementing Regulation (EU) 2024\/2690. Under that template the entity establishes risk criteria and a risk tolerance level. It then identifies, analyses and evaluates the risk and turns the result into a risk treatment plan with an owner and a deadline for each measure. It monitors the implementation of the plan. In entities applying Regulation 2024\/2690 the risk assessment results and residual risks are accepted by the management bodies or, where applicable, by persons who are accountable and have the authority to manage risks. The condition is that the entity ensures adequate reporting to the management bodies (point 2.1.1). For other entities I recommend that the head of the entity accept the residual risk, including for the period in which the measures are being implemented. It is advisable to review the results and the plan at least once a year and after significant changes to operations or risks or after a significant incident. For entities applying Regulation 2024\/2690 this is an obligation (point 2.1.4).<\/p>\n\n\n\n

Important entities that are public entities or the science units indicated in Article 8(3) apply Annex 4 to the Act instead of Article 8(1) in respect of their public tasks. According to the minister a public entity applying Annex 4 formally has no obligation to carry out a risk assessment (Q&A 3.15). However, Article 8(3) does not exclude Article 10, which requires a risk assessment for infrastructure facilities. According to the minister the entities listed in Article 8b(1) and trust service providers apply Regulation 2024\/2690 only in the activity to which it relates (Q&A 3.47). Entities in the banking and financial market infrastructure sectors keep the risk assessment obligation (Article 8i(1)), and according to the minister DORA takes precedence for them (Q&A 14.2). Specific rules also apply to some entities in the electricity subsector, former operators of essential services and some telecommunications undertakings. An entity that met the criteria for recognition as an essential or important entity on 3 April 2026 implements the system by 3 April 2027 (Article 33(1) of the amending act). Other entities have 12 months from meeting the criteria or from the delivery of the decision recognising them.<\/p>\n<\/div>\n\n\n\n

Why this question arises at all<\/h2>\n\n\n\n

Risk assessment opens the information security management system. Article 8(1) places it in point 1, and the measures under point 2 are to be appropriate and proportionate to the assessed risk. The catalogue in point 2 indicates the areas of measures, and the result of the assessment determines their selection and strength alongside costs and the size of the entity.<\/p>\n\n\n\n

The Act also defines risk and risk management. Risk is a combination of the likelihood of an undesirable event occurring and its consequences (Article 2(12)). Risk management means coordinated activities in the field of cybersecurity management with regard to the assessed risk (Article 2(19)). The Act does not specify the scale, the frequency or the acceptance threshold. According to the minister risk should be regularly identified, analysed and evaluated, followed by a decision on how to approach it (Q&A 3.3).<\/p>\n\n\n\n

A binding process template applies to the entities listed in Article 8b(1), for which point 2.1 of the Annex to Regulation 2024\/2690 describes the risk management framework. Under Article 8b(2) other entities apply the measures laid down for their type in Commission implementing acts adopted under Article 21(5) of the NIS2 Directive. For trust service providers such an act is Regulation 2024\/2690 (Article 1 of the Regulation and Q&A 14.1). In the October 2026 update the minister lists no other such acts (Q&A 14.1), and the Council of Ministers has not yet used the authorisation under Article 8a. High-impact and critical-impact entities in the electricity subsector additionally have a binding process template for the assets in their high-impact and critical-impact perimeters (Article 26 of Commission Delegated Regulation (EU) 2024\/1366 and Article 8b(3)). Other entities outside the sector covered by Article 8i therefore have no binding process template. It is advisable for them to be able to justify the chosen method, because the authority may request evidence of compliance with the requirements of Article 8(1) (Article 53(2)(6) and Article 53(17)).<\/p>\n\n\n\n

What has to be established before a decision<\/h2>\n\n\n\n

Who risk assessment applies to and from when<\/h3>\n\n\n\n

The implementation deadline under the Act is common to all types of entities. An entity that met the criteria on 3 April 2026 implements the system by 3 April 2027 (Article 33(1) of the amending act). An entity that met them later has 12 months from meeting them (Article 16(1)). An entity recognised by a decision counts 12 months from its delivery (Article 7l(7) and Article 7m(6)). Until the new system is implemented, former operators of essential services apply the existing system (Article 33(6) of the amending act). Telecommunications undertakings that performed obligations under Division VIIa of the Telecommunications Law before 3 April 2026 perform them under the previous provisions until they start performing the obligations under Chapter 3 of the KSC Act (Article 33(5) of the amending act). A public entity performs the obligations under Article 8 if it uses an information system to perform a public task (Article 16d).<\/p>\n\n\n\n

Type of entity<\/th>Reference point for risk assessment<\/th>Exceptions and limitations<\/th><\/tr><\/thead>
Essential or important entity \u2014 general rule<\/td>Article 8(1)(1) of the Act and the method described in the entity’s policy<\/td>covers the information systems used in processes that affect the provision of the service<\/td><\/tr>
Entities listed in Article 8b(1), among others cloud computing service providers and managed service providers, and trust service providers (Article 8b(2))<\/td>Article 8(1)(1) of the Act and point 2.1 of the Annex to Regulation 2024\/2690<\/td>according to the minister the Regulation applies only to the activity to which it relates (Q&A 3.47)<\/td><\/tr>
Important entity that is either a public entity or a unit of the higher education and science system indicated in Article 8(3) that is not a research organisation \u2014 in respect of public tasks performed using information systems<\/td>Annex 4 instead of Article 8(1); documentation of infrastructure protection with a risk assessment for infrastructure facilities (Article 10(3)(2)(c) and Article 16d)<\/td>according to the minister a public entity formally has no risk assessment obligation (Q&A 3.15), although Article 8(3) does not exclude Article 10; review of the system at least once a year or without delay after a recommendation of the Government Plenipotentiary for Cybersecurity concerning the entity or after circumstances that may affect the risk of a significant incident and require the activities described in the system to be performed again or the system itself to be changed (Part III); a higher education institution that is a research organisation applies Article 8(1) (Article 8(3) and Q&A 3.27)<\/td><\/tr>
High-impact or critical-impact entity in the electricity subsector<\/td>Article 8(1)(1) of the Act and additionally the measures under Regulation 2024\/1366 (Article 8b(3)), including cybersecurity risk management for all assets in the high-impact and critical-impact perimeters and, every three years, risk management covering the phases in Article 26(2) (Article 26 of the Regulation)<\/td>applies to entities identified by the minister competent for energy (Article 52a(2))<\/td><\/tr>
Essential or important entity in the banking and financial market infrastructure sectors<\/td>Article 8(1)(1) of the Act; according to the minister DORA takes precedence in these sectors (Q&A 14.2), so it is advisable to carry out the assessment within ICT risk management (Articles 6 and 8 of DORA)<\/td>the other provisions on the management system, including the policy under point (a), do not apply except Article 8(1)(2)(j) (Article 8i(1)); in my assessment this also applies to Article 10; Articles 8c to 8f apply accordingly (Article 8i(2)); supervision is exercised by the Polish Financial Supervision Authority (Article 8i(3) and Article 41(4))<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

According to the minister an entity in the banking and financial market infrastructure sectors applies the Act without the exclusions under Article 8i in activities other than financial ones, for example when providing cloud computing services (Q&A 14.13).<\/p>\n\n\n\n

According to the minister the risk-based approach was abandoned in Annex 4 because smaller local government units do not have the appropriate staff (Q&A 3.14). The minister adds that risk analysis is not prohibited and that an analysis of the risk to persons is necessary to apply Article 32 GDPR (Q&A 3.15). I recommend at least a simplified risk assessment, because without one it is hard to choose which elements of Part II to implement. According to the minister the entity should consider them if its circumstances allow (Q&A 3.40).<\/p>\n\n\n\n

What risk assessment covers<\/h3>\n\n\n\n

The subject is the risk of an incident occurring. An incident is an event that has or may have an adverse effect on the security of information systems (Article 2(5)). The definition is not limited to attacks. A power failure, a flooded server room or an administrator’s error can also be such an event. Regulation 2024\/2690 calls this an all-hazards approach (point 2.1.2(d) of the Annex).<\/p>\n\n\n\n

The scope is set by the service and in a public entity also by the public task (Article 2a). The management system covers the information system used in processes that affect the provision of the service (Article 8(1)). An information system is an ICT system or a device or group of interconnected devices and software programmed to process data. It also covers data processed in electronic form (Article 2(14)). According to the minister the definition also includes industrial automation systems (Q&A 6.6).<\/p>\n\n\n\n

According to the minister the starting point is the processes of providing the service, including those required by law, for example handling customers’ rights. For each system the minister advises checking three things. The first is whether the system is necessary for the service. The second is whether the system processes data and controls processes on which the service depends. The third is whether an event in the system can interrupt the provision of the service. The minister excludes systems fully separated from the service and without impact on it. However, supporting systems such as accounting systems should be included when the service cannot be provided without them (Q&A 3.4).<\/p>\n\n\n\n

Risk under the GDPR concerns the rights and freedoms of natural persons (Article 32(1)), while risk under the KSC Act concerns an incident in the systems on which the service depends. If both processes use a common register, it is advisable to evaluate the impact on the service and on persons separately in it.<\/p>\n\n\n\n

How to carry out a risk assessment step by step<\/h3>\n\n\n\n

For the entities listed in Article 8b(1) and trust service providers the steps are set by point 2.1.2 of the Annex to Regulation 2024\/2690. The Regulation requires a risk management methodology to be followed but does not choose the method itself. For entities without a binding template it is the closest official template, and I recommend it as the framework for their own method. According to the minister the Regulation was based among others on the ISO\/IEC 27001 and 27002 standards (Q&A 14.1). According to the minister an organisation with an information security management system under one of the available standards may use and adapt its existing documentation (Q&A 3.6).<\/p>\n\n\n\n

    \n
  1. Scope.<\/strong> List the services covered by the Act and the systems supporting them, and indicate an owner for each system. The asset inventory in Regulation 2024\/2690 includes the list of operations and services and their description and the list of network and information systems and other associated assets supporting the operations and services (point 12.4.2). According to the minister every system through which the service is provided should be inventoried (Q&A 14.7).<\/li>\n\n\n\n
  2. Criteria.<\/strong> Set a likelihood scale, an impact scale and a way of combining them into a risk level, for example by multiplying them. Describe each level of the scale in words, because without that two people will rate the same scenario differently. Record a risk tolerance level in accordance with the risk appetite of the organisation (point 2.1.2(b) and (c)). In practice it is the level that the organisation accepts without additional measures. Describe impacts in the language of the service, for example as downtime and the number of users affected. It is advisable for the scale to cover also the loss of confidentiality, integrity and authenticity of data (Article 2(3d)). In control systems it is advisable to add a category of impacts on human health and the environment. Article 8(1)(2) lists social and economic effects among the circumstances relevant to the selection of measures, so it is advisable to include them in the scale. It is advisable to refer scenarios with the highest impact to the head of the entity for decision regardless of the product of likelihood and impact, because likelihood 1 and impact 5 give the same level as likelihood 5 and impact 1.<\/li>\n\n\n\n
  3. Identification.<\/strong> For each service describe event scenarios involving its systems and the safeguards in place. Do not match every asset with every threat, because a register of hundreds of items is hard to discuss with the board. Take into account risks relating to third parties and single points of failure, because Regulation 2024\/2690 names them expressly (point 2.1.2(d)). For cloud services also assess the elements on the entity’s side, that is configuration, identities and data backups. It is advisable to use the incident register kept as part of incident handling (Article 2(10)) and records of potential events that did not occur or were prevented (Article 2(11e)).<\/li>\n\n\n\n
  4. Analysis.<\/strong> Assess the likelihood and impact of each scenario taking into account cyber threat intelligence and vulnerabilities (point 2.1.2(e)) and the safeguards in place. Combining likelihood and impact gives the risk level (Article 2(12)). Impacts on the service are easiest to estimate on the basis of a business impact analysis. Entities applying Regulation 2024\/2690 must carry one out (point 4.1.3). For other entities it is advisable to start in the first cycle with a simplified version that sets the acceptable downtime of each service.<\/li>\n\n\n\n
  5. Evaluation.<\/strong> Compare the risk levels with the criteria (point 2.1.2(f)) and rank them from the highest. Risk exceeding the tolerance level requires a decision on how to treat it. Risk within tolerance does not require an additional measure, but it forms part of the residual risk presented for acceptance.<\/li>\n\n\n\n
  6. Risk treatment.<\/strong> Usually a mitigating measure is chosen from the catalogue in Article 8(1)(2) or from outside it. A change of process that removes the source of the risk is also possible, as is transferring part of the financial consequences to an insurer. Transferring the consequences does not transfer the obligations under the Act, which rest on the entity. I recommend accepting risk that exceeds the threshold only temporarily and with a decision of the head of the entity. Measures are prioritised taking into account among others the cost of implementation in relation to the expected benefit and the results of the procedure to assess the effectiveness of cybersecurity risk-management measures (point 2.1.2(g) and point 2.1.3). Record the result in the risk treatment plan with the measure, owner and deadline (point 2.1.2(i) and (j)). Present the budget of the plan to the head of the entity, who plans the financial resources for cybersecurity (Article 8d(2)). Monitor the implementation of the plan continuously (point 2.1.2(h)).<\/li>\n\n\n\n
  7. Acceptance of residual risk.<\/strong> Under Regulation 2024\/2690 the risk assessment results and residual risks are accepted by the management bodies or, where applicable, by persons who are accountable and have the authority to manage risks. The Regulation makes this conditional on the entity ensuring adequate reporting to the management bodies (point 2.1.1). The reasons justifying the acceptance of residual risks are documented in a comprehensible manner (point 2.1.2(j)).<\/li>\n<\/ol>\n\n\n\n

    The Act does not mention the acceptance of residual risk by name. In my assessment it is one of the decisions on the application of the system that Article 8d(1) entrusts to the head of the entity. Article 8c(3) argues against an obligation of personal acceptance, because it presupposes that obligations may be entrusted to another person with that person’s consent. Article 8e(1) likewise presupposes that the head’s obligations may be entrusted to another person. The minister also stresses the head’s freedom in organising the tasks of the system (Q&A 3.44). Whichever reading is adopted, the head supervises the performance of the assigned tasks and remains responsible for Article 8 even after entrusting them (Article 8d(3) and Article 8c(1) and (3)). If the head has entrusted this decision to another person, I recommend that the head at least receive a summary of the accepted risks with their justification.<\/p>\n\n\n\n

    Example of a single register item (fictitious data).<\/strong> A water utility that is an essential entity assesses the control system of a water treatment plant. The system is serviced remotely by a supplier.<\/p>\n\n\n\n