KSC in 2026: the Polish national cybersecurity system act after the NIS2 transposition

Origins and legal basis: from NIS to KSC

The national cybersecurity system act entered into force on 28 August 2018, transposing directive (EU) 2016/1148 (NIS) of the European Parliament and of the Council. It was the first systemic cybersecurity regulation in Polish law. Earlier provisions - the GDPR, the KRI regulation, the classified information act - covered selected areas, but there was no framework regulation reaching the sectors critical to the national economy.

KSC establishes three levels of structure:

• Strategic level - the Government Plenipotentiary for Cybersecurity, the Cybersecurity College and the minister for digital affairs (currently the Minister of Digital Affairs). Approval of the national strategy, cross-sector coordination, international cooperation.
• Operational level - three national-level CSIRTs (NASK, GOV, MON), the competent authorities for each sector, and sectoral CSIRT teams. Incident response, national coordination, support for entities covered by the act.
• Executive level - essential and important entities. Implementing the information security management system, monitoring, reporting incidents, auditing.

The legislator's premise was to delegate the technical duties to the executive level - the entity itself organises its information security management system - while the state retains a coordinating, normative and crisis support role. The model was carried over from the NIS directive and retained in NIS2.

The Cybersecurity Strategy of the Republic of Poland for 2019-2024 ^[6], adopted by the Council of Ministers on 22 October 2019, defined the goals of state policy in this area and provided a basis for further development of KSC and the preparations for NIS2. It has since been replaced by the new Cybersecurity Strategy of the Republic of Poland, adopted on 10 March 2026 and in force since 24 March 2026.

Scope: essential and important entities

Since 3 April 2026 the act no longer uses the notions of operator of essential services or digital service provider. It divides the addressees of its duties into essential entities and important entities, and membership is decided by combining a sector from annex 1 or annex 2 with the size of the entity, measured under annex I to EU regulation 651/2014.

Essential entity (article 5(1))

• An entity listed in annex 1 that exceeds the requirements for a medium enterprise.
• An electronic communications undertaking of at least medium size.
• A managed cybersecurity service provider of at least small size - the threshold here is markedly lower than in the other sectors.
• Regardless of size: DNS service providers, qualified trust service providers, critical entities, public entities listed in annex 1 in the public entities sector, top-level domain name registries, entities providing domain name registration services, operators of nuclear power facilities, and entities identified individually under articles 7l and 7m.

Important entity (article 5(2))

• An entity from annex 1 meeting the requirements for a medium enterprise that is not an essential entity.
• An entity from annex 2 meeting or exceeding the requirements for a medium enterprise that is not an essential entity.
• A non-qualified trust service provider that is a micro, small or medium enterprise.
• An electronic communications undertaking that is a micro or small enterprise.

What this changes in practice

Three differences against the previous legal state matter most operationally.

• There is no list drawn up from above. Previously an operator of essential services was designated by administrative decision and there were several hundred of them in Poland. Today the obligation arises by operation of law and the entity files its own application for entry in the register.
• An important entity has a narrower set of duties. The periodic audit under article 15 does not apply to it, though the competent authority may order an external audit after a significant incident.
• The public sector entered the act expressly. Public entities listed in the annexes are covered regardless of size, and those of them that are important entities build their management system according to annex 4.

Local government units are not covered automatically. Status depends on whether the given unit or its organisational unit fits the description of the type of entity in the annex. Independently of that, local government is subject to the KRI regulation, which imposes its own duty to run an information security management system and an annual internal audit.

Sectors under annexes 1 and 2

Sector membership is the first of two conditions for being covered by the act. The second is the size of the entity. The annexes themselves do not list sectors in general terms - for each subsector they indicate the type of entity by reference to sectoral legislation, for example to a licence under the geological and mining law or to the definition of an energy undertaking in the energy law. A self-assessment therefore requires reading the annex, not merely recognising your own industry.

Annex 1: essential sectors

• Energy - with subsectors covering mineral extraction, electricity, heat, oil and fuels, gas and hydrogen.
• Transport - air, rail, water and road.
• Banking and financial market infrastructure.
• Health care - including the manufacture and distribution of active substances, medicinal products and medical devices.
• Drinking water supply and distribution.
• Waste water - excluding entities for which the discharge or treatment of waste water is a non-essential part of their activity.
• Digital infrastructure.
• ICT service management.
• Space.
• Public entities.

Annex 2: important sectors

• Postal and courier services.
• Waste management - collection, transport and treatment.
• Manufacture, production and distribution of chemicals.
• Production, processing and distribution of food.
• Manufacturing - of medical devices and in vitro diagnostic devices, computers, electronic and optical products, electrical equipment, machinery and equipment, motor vehicles, trailers and semi-trailers, and other transport equipment.
• Digital service providers.
• Scientific research.
• Public entities.

Why the significance thresholds disappeared

Under the previous legal state, coverage was decided by an administrative decision of the competent authority, issued after checking the significance thresholds for the disruptive effect set out in a Council of Ministers regulation - for example the number of energy customers or the number of hospital beds. That mechanism was replaced by the criterion of sector plus size of entity, common to the whole Union. The Council of Ministers regulation of 11 September 2018 on the list of essential services and significance thresholds^[2] was repealed with effect from 3 April 2026. The numerical thresholds in that instrument are no longer a basis for qualification and should not be relied on.

This does not mean quantitative criteria vanished altogether: they still appear inside the descriptions of types of entity in the annexes, wherever the legislator refers to sectoral legislation that carries thresholds of its own.

Duties of essential and important entities

The core of the act is chapter 3, articles 8 to 16. Below are the duties in the order in which they are actually implemented.

Information security management system (article 8)

An essential or important entity implements an information security management system in the information system used in processes affecting the provision of the service. The act sets out what that system must ensure:

1. Systematic assessment of the risk of an incident occurring, and management of that risk.
2. Technical and organisational measures appropriate and proportionate to the assessed risk, taking into account the state of the art, the cost of implementation, the size of the entity and the socio-economic effects. The act lists fourteen areas, from risk assessment and system security policies, through security in the acquisition, development, maintenance and operation of the system including testing, physical and environmental security, human resources security, supply chain security, business continuity and recovery plans, continuous system monitoring, assessment of the effectiveness of safeguards, staff education, basic cyber hygiene practices, cryptography and encryption, secure communication means with multi-factor authentication, to asset management and access control policies.
3. Collecting information on cyber threats and vulnerabilities.
4. Incident management.
5. Measures preventing and limiting the impact of incidents - mechanisms for the confidentiality, integrity, availability and authenticity of data, regular software updates with an analysis of the impact on the security of the service, protection against unauthorised modification, and immediate action once a vulnerability is spotted, up to and including temporary restriction of inbound traffic.

On supply chain security the act requires four things to be taken into account under article 8(2): the vulnerabilities of the specific supplier, the overall quality of its products and services, the results of the coordinated security risk assessment carried out by the EU Cooperation Group, and the outcome of proceedings on designating a supplier as a high-risk supplier.

A separate path for part of the public sector. An important entity that is a public entity does not apply article 8(1) but builds its management system according to annex 4 to the act, under article 8(3). The annex is shorter and more concrete: it lists, among other things, an inventory of ICT products, services and processes, version control, the principle of least privilege, backups separated logically and physically together with restore testing, antivirus software, cyber hygiene rules extending to the head of the entity, and monitoring of the life cycle of the ICT products in use.

Entry in the register (article 7c)

The application for entry in the register of essential and important entities is filed within six months of the day the conditions are met. Changes to the data are reported within 14 days. The application is signed by the head of the entity with a qualified, trusted or personal electronic signature and carries a declaration that the data are true, made under criminal liability.

Contact persons and informing users (article 9)

The entity designates at least two persons responsible for contact with the bodies of the national cybersecurity system. A micro or small enterprise, and an important entity that is a public entity, designate at least one. Beyond that, the entity makes knowledge of cyber threats and protection methods available to the users of its service - a link to the website of the competent authority or a CSIRT is enough - and provides a channel for reporting cyber threats, incidents and vulnerabilities.

Documentation (article 10)

The act splits documentation into normative and operational. The normative set consists of: the management system documentation, the infrastructure protection documentation (a description of the service and infrastructure, an assessment of the state of protection, risk assessment for facilities, a risk treatment plan, a description of technical safeguards and physical protection rules), the business continuity management system documentation, and the technical documentation of the system.

Incident reporting (articles 11 and 12)

The sequence has three stages and runs from the moment of detection:

• Early warning - without delay and no later than within 24 hours, to the competent sectoral CSIRT. It contains the entity's details, the reporting person, the time of occurrence and of detection, the duration, an indication whether the incident resulted from unlawful or bad-faith action, and whether it affects other member states.
• Report of a significant incident - within 72 hours. It describes the impact on the provision of the service, the number of users affected, the geographic reach, the causes, the course of events, the likely consequences and the preventive and remedial actions taken.
• Final report - no later than one month from the report. At the request of the sectoral CSIRT, interim reports are added.

An exception: a trust service provider reports a significant incident within 24 hours of detection, under article 11(1a).

The early warning may include a request for guidance or for technical support, and the sectoral CSIRT has 24 hours to respond. The entity also informs its own users where the incident adversely affects the services provided to them, and, in the case of a significant cyber threat, about possible preventive measures.

The thresholds for treating an incident as significant are set by a Council of Ministers regulation, separately for sectors and subsectors; for some entities the thresholds follow directly from a European Commission implementing act.

Structures responsible for cybersecurity (article 14)

To carry out the tasks under article 8 and articles 9 to 13, the entity establishes internal structures responsible for cybersecurity or concludes a contract with a managed cybersecurity service provider. The act does not prescribe a model and does not expressly require 24/7 operation - but the duty of continuous system monitoring under article 8(1)(2)(g) and the 24-hour early warning deadline force round-the-clock response capability in practice. See SOC 24/7.

Management training (article 8e) and criminal record checks (article 8f)

The head of the entity and any person entrusted with the head's duties in the area of cybersecurity attend, once every calendar year, training covering the performance of duties under articles 7b(4), 7c, 7f(3), 8, 8d, 8f, 9 to 12b, 14 and 15. Attendance must be documented - one of the simplest pieces of evidence to produce during an inspection, and one of the most frequently missing.

Separately, article 8f requires that, before starting to perform tasks under article 8 or article 11, the person concerned provides the entity with information about themselves from the National Criminal Register.

Audit (article 15) and transitional deadlines (article 16)

An essential entity carries out an audit at least once every three years - details in the section below. Article 16 allows 12 months for the duties under this chapter and 24 months for the first audit, counted from the day the conditions for being an essential or important entity are met.

Continuous monitoring and incident management

KSC does not impose a universal requirement to operate a facility or team called a 24/7 SOC. The regulation of the Minister of Digital Affairs of 4 December 2019 ^[8] governed service providers and internal structures under the former operator-of-essential-services model, but it was repealed on 3 April 2026. It is therefore not a current legal basis for prescribing particular staff certificates, security products or a fixed log-retention period.

Organisational implications of the current act

• Responsible structure - an internal cybersecurity structure or a contract with a managed cybersecurity service provider under article 14.
• Response capability - staffing and on-call arrangements proportionate to the risk, the service and the statutory reporting deadlines.
• Documented procedures - incident classification, internal escalation, evidence preservation, containment and recovery.
• External escalation - reporting to the competent CSIRT in accordance with the transition rules for sectoral CSIRTs.

Technical implications

• Continuous monitoring - the information system used to provide the service must be monitored continuously under article 8(1)(2)(g). A SIEM, EDR, XDR or NDR platform may support this duty, but the act does not mandate a named product category.
• Detection coverage - controls should reflect the entity's systems and risk assessment, including endpoints, identities, networks, cloud services and email where relevant (see email security audit and DMARC).
• Cyber-threat and vulnerability information - the entity collects and uses relevant information, including material from CERT Polska ^[5] and sector-specific sources.
• Logs and evidence - the scope, integrity protection and retention period follow from the risk assessment, sectoral rules and other applicable law; KSC does not establish a universal 12-month retention period for all system logs.

Incident classification

KSC, in article 2(5) to (7), introduces a three-tier classification:

• Critical incident - one causing significant disruption to an essential service. Threshold: loss of availability above 24 hours for at least 50 per cent of recipients, or a breach of integrity affecting human health or life, for example in hospitals.
• Significant incident - one causing material disruption. Threshold: loss of availability of 4 to 24 hours, or a breach of confidentiality affecting a large number of records, for example above 100,000.
• Notable incident - one causing disruption on a smaller scale but still requiring attention.

Each level has a different reporting route: critical and significant incidents go to a CSIRT within 24 hours, notable ones into the quarterly report.

Practical SOC challenges under KSC

The three biggest problems we see at entities covered by the act:

1. Skills shortage - the domestic market has a limited number of L3 specialists and the cost of an in-house team reaches PLN 1.5 to 3 million a year. That is why most entities choose to outsource the SOC.
2. False positive fatigue - a badly configured SIEM produces thousands of alerts a day, most of them false. This calls for tuning and use case engineering.
3. No OT integration - the energy, water and transport sectors run industrial automation systems (SCADA, PLC) that need specialist monitoring (Claroty, Nozomi, Dragos). A traditional IT SOC does not cover OT without additional configuration.

National-level CSIRTs: NASK, GOV, MON

KSC creates three national-level CSIRTs with different areas of competence:

CSIRT NASK

Run by the Research and Academic Computer Network, National Research Institute (NASK). Competent for:

• Entities in civil sectors: banking, transport (outside the special cases), water supply, digital infrastructure (outside government administration).
• Digital service providers.
• Telecommunications operators, on a cooperation basis.

CSIRT NASK also runs the publicly known unit CERT Polska, the oldest incident response team in Poland, operating since 1996. It publishes an annual report ^[5] analysing the cyber threat landscape^[9].

CSIRT GOV

Run by the Internal Security Agency (ABW). Competent for:

• Government administration - ministries, central offices, government agencies.
• National critical infrastructure in the sectors of energy (system operators), transport (the air navigation agency PAZP, the rail infrastructure manager PKP PLK) and the part of the financial sector covering market infrastructure.
• Selected public entities designated by the Government Plenipotentiary.

CSIRT MON

Run by the Ministry of National Defence and the Cyberspace Defence Forces Component Command (DKWOC). Competent for:

• The Polish Armed Forces and organisational units of the Ministry of National Defence.
• Undertakings of particular economic and defence significance.
• Military research and development bodies and the defence industry.

Cooperation between CSIRTs

The three CSIRTs cooperate within the national incident response network. Where an incident affects more than one area of competence - for example a ransomware attack on a supply chain covering both the civil sector and administration - there is coordination at the operational level. The national-level CSIRTs also work with the European CSIRT Network established by the NIS directive and exchange information through ENISA.

Sectoral CSIRT teams

Some sectors have additional sectoral CSIRTs, for example FinCERT.pl for the banking sector, run by the Polish Bank Association, and CSIRT-KRD covering certain institutions. Sectoral CSIRTs act as a first reporting line and pass information on to the national-level CSIRTs.

The KSC audit: every three years

The information system security audit under article 15 of the act is the mandatory and best-defined element of external control. An essential entity carries it out at its own expense, at least once every three years, counted from the day the report on the previous audit was drawn up and signed by the auditors.

The cycle changed on 3 April 2026. Until that day article 15 required an audit at least once every two years. Four points cause the most trouble in practice:

• The duty applies to essential entities. An important entity has no periodic audit duty under article 15 - but the competent authority may order it to undergo an external audit in the event of a significant incident or another breach of the act, under article 15(1b), and that decision is immediately enforceable.
• The deadline for the first audit is counted individually. Article 16 allows 12 months for the duties under chapter 3 and 24 months for the first audit, but both periods run from the day the conditions for essential or important entity status are met, not from the entry into force of the amendment. For entities that already met the conditions on the day the amendment entered into force, the period runs from that date under article 33 of the amending act^[4]: chapter 3 duties by 3 April 2027, the first audit by 3 April 2028. The popular "first audit by 3 April 2028" is therefore correct only for that group.
• The report within three working days. A copy of the report goes to the competent authority in electronic form within three working days of its receipt, under article 15(1a). This deadline is easy to miss, because it runs from receipt of the report, not from the end of the audit work.
• The clock runs from the signature, not from the calendar year. The three years run from the date the previous report was signed, so a delay to one audit shifts the whole cycle.

Who may act as auditor

The act sets out three permissible options in article 15(2):

1. A conformity assessment body accredited under the act of 13 April 2016 on conformity assessment and market surveillance systems, in the scope relevant to information system security assessments.
2. At least two auditors holding certificates from the list set out in a regulation of the minister for digital affairs, or with at least three years of practice in information system security auditing, or two years of practice together with relevant postgraduate studies.
3. A sectoral CSIRT, if its auditors meet the conditions in point two.

There is a separate, hard independence rule: the audit may not be carried out by a person who performs the tasks under article 8 and articles 9 to 13 in the audited entity, or performed them within the year preceding the start of the audit, under article 15(2a). This rules out the implementer checking their own work - including where they have changed employer in the meantime.

Scope of the audit

The audit covers at least three planes:

• Documentary - policies, procedures, risk analysis, continuity plans, contracts with suppliers, records of incidents and of management decisions.
• Technical - configuration of systems and network devices, safeguards, access management, segmentation, logs and continuous monitoring. The auditor verifies through sampling and testing, not through declarations.
• Organisational - staff awareness, training, incident handling in practice, continuity exercises, escalation paths.

The audit report

The report contains:

• Findings - observations of non-compliance with the requirements of the act and with the adopted reference standard.
• A classification of non-conformities - major, minor, observations.
• Recommended corrective actions.
• A deadline for closing the non-conformities.
• An overall assessment of the state of the information security management system.

A copy of the report goes to the competent authority. On request it is also provided to the director of the Government Centre for Security, where the entity is at the same time an operator of critical infrastructure, and to the Head of the Internal Security Agency, under article 15(7).

Cost of the audit

The ranges below come from our own practice and depend primarily on the number of systems in scope, not on the size of the organisation as such.

• An entity with a narrow scope, for example a district hospital: PLN 25,000 to 50,000.
• A medium entity, for example an electricity distributor: PLN 50,000 to 120,000.
• An entity with extensive infrastructure, for example a transmission system operator or a domestic bank: PLN 150,000 to 500,000.

These amounts cover the documentary part, the technical part and the report. They do not cover corrective actions, which are usually a larger expense than the audit itself.

Penalties and sanctions

Administrative fines are imposed by the authority competent for cybersecurity. The catalogue of breaches is long - article 73(1) lists twenty-two of them - and covers, among other things, the absence of an information security management system, the absence of risk assessment, failure to report a significant incident on time, failure to carry out the audit, failure to remove vulnerabilities indicated by the authority, and obstruction of an inspection.

Upper limits

• Essential entity - up to EUR 10 million or 2 per cent of turnover from business activity for the previous financial year, whichever is higher. The fine may not be lower than PLN 20,000.
• Important entity - up to EUR 7 million or 1.4 per cent of turnover, not less than PLN 15,000.
• Aggravated form of the breach - where the breach causes a direct and serious cyber threat to defence, state security, public order or human life and health, or risks serious material damage or serious disruption to the provision of services, the authority imposes a fine of up to PLN 100 million, under article 73(5).

Amounts in euro are converted at the average National Bank of Poland rate as at 31 December of the year preceding the year in which the decision is issued. Where the entity has been in operation for less than 12 months or has generated no turnover, the basis is the equivalent of EUR 500,000 for an essential entity and EUR 250,000 for an important one.

Fine on the head of the entity

The head of the entity is separately liable under article 73a for failing to perform duties relating to entry in the register, the information security management system, risk analysis or the designation of contact persons. The fine reaches 300 per cent of the remuneration of the person penalised, calculated as for holiday pay, and 100 per cent of remuneration in a public entity.

This is a qualitative change against the previous legal state, in which the maximum fine on the entity was PLN 200,000, or PLN 1 million on repeat breach, with no personal sanction at all. The practical consequence is that cybersecurity has ceased to be a topic the board can delegate wholesale to the IT department.

What the 2026 amendment changed

The NIS2 directive ^[3] replaced the NIS directive of 2016. Poland transposed it by the act of 23 January 2026 (Journal of Laws 2026 item 252)^[4], which entered into force on 3 April 2026. Below is what actually changed - useful if your organisation's documentation was written for the previous legal state.

The OUK and DUC categories are gone

Operator of essential services and digital service provider are notions from the earlier wording of the act. They were replaced by essential entity and important entity. The change is not cosmetic: the basis for being covered is different (a sector and size criterion instead of an administrative decision), the registration procedure is different and the catalogue of duties is different.

The end of administrative decisions, the start of self-registration

Previously the competent authority issued a decision recognising an operator of essential services, and that decision triggered the duties. Today the entity assesses for itself whether it meets the conditions and files an application for entry in the register of essential and important entities within six months of meeting them, under article 7c(1). Changes to the data are reported within 14 days. The application contains a declaration by the head of the entity made under criminal liability for false statements.

The practical consequence is uncomfortable: nobody will send a notification. An organisation that does not carry out the self-assessment will learn its status only during an inspection.

An extended catalogue of sectors

Annex 1 gained, among others, waste water, ICT service management (managed service providers and managed cybersecurity service providers), space and public entities. Annex 2 introduced sectors not previously covered by the act: postal and courier services, waste management, chemicals, food, manufacturing, digital service providers and scientific research.

Three-stage incident reporting

Previously a single report within 24 hours applied. Today the sequence is: early warning within 24 hours, report within 72 hours, final report within one month, under article 11(1)(4) to (4c). The addressee is the sectoral CSIRT, not the national-level CSIRT directly.

Management liability

The act provides for an administrative fine imposed personally on the head of an essential or important entity, under article 73a. This is a departure from a model in which the sanction fell solely on the organisation.

The audit cycle from two years to three

Before 3 April 2026 article 15 required an audit at least once every two years. It is now once every three years and, equally importantly, the duty applies only to essential entities.

What to do if the organisation has not started

1. Self-assess your status. A sector from annex 1 or 2, plus the size of the entity under EU regulation 651/2014. The result must be documented even when it is negative.
2. Apply for entry in the register if the conditions are met - the deadline runs from the day they are met, not from the date the amendment entered into force.
3. Gap analysis between the existing documentation and articles 8 to 13 of the act.
4. Supplier inventory - article 8(2) requires the vulnerabilities of the specific supplier and the overall quality of its products and services to be taken into account.
5. Management training. With the personal sanction under article 73a, this is not a cosmetic item.

Mapping to other frameworks

KSC does not exist in a vacuum - mapping to other regulations is central to efficient compliance:

KSC and PN-ISO/IEC 27001

KSC refers directly to PN-ISO/IEC 27001 ^[7] as the base standard for an information security management system. In practice holding an ISO 27001 certificate makes meeting the KSC requirements considerably easier - a KSC audit then covers a smaller additional scope, namely the sector-specific matters and incident reporting. Details in the article on ISO 27001.

KSC and KRI

The KRI regulation, the Polish national interoperability framework of 21 May 2024, applies to entities performing public tasks. KSC applies to essential and important entities. The scopes do not overlap by sector, but the technical requirements are very similar, since both refer to PN-ISO/IEC 27001. A local government unit may be subject to KRI as a public entity and to KSC at the same time, if for example it runs a hospital that exceeds the threshold. Details in the article on KRI.

KSC and NIS2

After the NIS2 transposition KSC remains a Polish statute, but its wording covers all the requirements of the directive. In practice organisations apply the amended KSC act - the NIS2 directive itself is not directly applicable. Details in the article on NIS2.

KSC and the GDPR

KSC and the GDPR are complementary: KSC protects the information system, the GDPR protects personal data. A KSC incident such as ransomware may at the same time be a GDPR breach, if the encrypted data contained personal data. In practice this calls for parallel notification: to a national-level CSIRT under KSC within 24 hours, and to the Polish data protection authority under the GDPR within 72 hours. Details in the article on the GDPR.

KSC and DORA

DORA, the Digital Operational Resilience Act for the financial sector, is lex specialis to NIS2 - for banks, financial institutions and their ICT suppliers, DORA replaces NIS2 in the area of operational resilience. A bank remains an essential entity for KSC purposes, but applies DORA to ICT risk management. Details in the article on DORA.

KSC and sectoral regulation

Energy sector: the Network Code on Cybersecurity, EU implementing regulation 2024/1366, adds requirements for electricity operators. Financial sector: the recommendations of the Polish Financial Supervision Authority, for example Recommendation D and Recommendation Z. Health sector: the Ministry of Health regulation on the medical information system.

The most common organisational mistakes

After years of KSC audits we see recurring mistakes:

1. The security policy is a template downloaded from the internet. The document exists but does not reflect the actual organisation. The data protection authority and the competent authority assess real implementation, not the document alone.
2. No documented risk analysis. Either there is none, or it is five years old, or it was never updated after material changes such as a cloud migration, a merger or expansion into new markets.
3. A business continuity plan on paper. The plan has never been tested. No tabletop exercises, no practical scenario such as a backup restore test or a fallback mode test.
4. A SOC with no response time SLA. The supplier contract exists but defines neither the response time nor the consequences of missing it. The SOC becomes a formality.
5. No real escalation to a CSIRT. The procedure exists but has never been tested. Staff do not know who reports, how, or in what format.
6. Logs are not centralised. Every system logs locally, with no SIEM and no correlation. After an incident, reconstructing the timeline takes weeks.
7. The KSC audit carried out by your own supplier. A conflict of interest - the auditor checks their own implementation. Non-compliant with article 15 of the act, and the audit report carries no credibility.
8. No supplier management. A list of suppliers exists, but without risk classification, without cybersecurity clauses in contracts and without a right to audit.
9. No security awareness training. Staff do not know how to recognise phishing or how to report an incident. There are no recurring sessions and no tests (see security awareness).
10. Systems hardened at default level. Servers, routers and network devices run factory configuration. No CIS benchmarks, no configuration scanning (see hardening).
11. No penetration testing. Vulnerability scanning is sometimes done, but there is no proper pentest every 12 to 24 months. That is an evidence gap in the audit (see penetration testing).
12. Backups with no restore tests. The classic - backups are taken but nobody has ever restored one. When ransomware hits, the backup turns out to be corrupt or incomplete.