KRI in 2026: section 19, the ISMS, the annual audit and the 2027 change

What KRI is

KRI forms part of the Polish legal framework for digitization of entities performing public tasks. The 2024 regulation defines ways of achieving interoperability and minimum requirements for public registers and ICT systems.^[1] Its statutory basis is the Act of 17 February 2005 on digitization of activities of entities performing public tasks.^[4]

The regulation is not limited to security. It addresses organizational, semantic and technological interoperability, data formats, public-register requirements and minimum requirements for ICT systems. Information security sits within the chapter on minimum system requirements.

Older procedures that still cite section 20 as the legal basis for the ISMS therefore point to the wrong provision. It is the most common formal defect we see in documentation during assessments.

Who KRI applies to

Scope should not be inferred from the name of an organization alone. The analysis must start with the Digitization Act and its Article 2, taking account of its current wording and transitional provisions.^[4][2] The Act primarily covers public entities, including public-finance-sector units, other state organizational units and specified legal persons that meet statutory public-control or public-financing conditions.

In practice, municipalities, counties, regions, offices and their budgetary units will generally fall within the statutory scope. For companies, institutions, universities and other legal persons, the precise statutory condition must be checked. Receiving a subsidy or carrying out socially useful activity is not, by itself, a substitute for that legal analysis.

Before an audit, it is useful to prepare a short scope memorandum: legal basis for coverage, organizational units, public tasks, systems supporting those tasks, locations, cloud services and suppliers. Without this, the audit can easily be too narrow or extend into areas without the proper criterion.

Section 19(1) - the ISMS requirement

Section 19(1) requires an ISMS that ensures confidentiality, availability and integrity of information, taking account of authenticity, accountability, non-repudiation and reliability.^[1]

The verbs in the provision matter: the system must be developed and established, implemented and operated, monitored and reviewed, and maintained and improved. A policy package without evidence of operation does not meet the substance of this requirement. What such a system looks like in practice is described on our information security management system page.

Section 19(2) - fourteen action areas

Subsection 2 requires management to provide conditions for implementing and enforcing at least the following areas:^[1]

1. updating internal regulations as the environment changes;
2. keeping an up-to-date inventory of hardware and software, including type and configuration;
3. periodic risk analyses and actions based on their results;
4. appropriate access rights for people involved in information processing;
5. prompt changes to access rights when duties change;
6. training on threats, consequences of violations and measures reducing human error;
7. monitoring access, detecting unauthorized activity and protecting operating systems, services and applications;
8. rules for secure mobile and remote work;
9. protecting information against unauthorized disclosure, alteration, deletion or destruction;
10. security requirements in service contracts with third parties;
11. rules for handling information and information-processing assets;
12. system security including updates, resilience to failure, cryptography, system-file protection and vulnerability handling;
13. a predefined method for reporting incidents;
14. an internal information-security audit at least once a year.

The provision uses wording equivalent to "in particular". The list should therefore not be treated as a closed maximum. Section 19(4) additionally requires further safeguards where justified by risk analysis.^[1]

The annual audit - what it actually means

Section 19(2)(14) requires a periodic internal information-security audit at least once a year.^[1] It does not prescribe a named auditor certificate, a minimum number of person-days or a ready-made checklist.

"Internal" describes the function of the audit within the management system; it does not necessarily mean that the auditor must be an employee of the entity. A competent external provider may be used. Whatever the model, objectivity, competence, criteria, scope, sampling and evidence must be addressed.

A good audit does not ask only whether a procedure exists. It checks, for example, whether the inventory matches actual devices, whether access was removed after role changes, whether backups can be restored, whether logs are complete, whether vulnerabilities lead to action and whether incidents are recorded and handled. We use a comparable approach in an IT security audit.

Section 19(3) - the role of PN-ISO/IEC 27001

The requirements of section 19(1) and (2) are deemed met where the ISMS is developed on the basis of PN-ISO/IEC 27001 and the establishment of safeguards, risk management and auditing are based on related Polish Standards, including PN-ISO/IEC 27002 and PN-ISO/IEC 27005.^[1][5][6][7]

This is a strong reference to standards, but it is not a certification mandate. The provision concerns how the system and processes are based on Polish Standards, not an obligation to hold a certificate issued by a certification body. The scope of the standard itself is covered on our ISO/IEC 27001 page, and the control catalogue on the ISO/IEC 27002 page.

A certificate can provide useful evidence about the operation of an ISMS within its certification scope, but it does not automatically replace the annual KRI audit. It is also necessary to check whether the certification scope covers systems and processes material to public tasks.

Section 20 - logs and accountability

Section 20 requires reliable documentation of accountability through system logs. Mandatory logging includes administrative access, access to system configuration including security settings, and access to legally protected data to the extent required by law.^[1]

Other user actions and system events are logged to the extent resulting from risk analysis. If separate legislation sets no different period, log information is retained for two years.^[1]

This does not mean that every system must collect every possible event for exactly two years. The scope of logging and longer retention may follow from other legislation, risk, contracts or evidentiary needs.

KRI and KSC after 3 April 2026

KRI and KSC are separate legal bases. KRI concerns ICT systems and interoperability within the scope of the Digitization Act. KSC, after implementation of NIS2, covers essential and important entities and imposes its own cybersecurity risk-management obligations.^[8]

One entity may fall under both regimes. Requirements should then be mapped, not treated as identical. The annual KRI audit and the audit under Article 15 KSC have different legal bases, scopes and cycles.

The transitional deadlines of the KSC amendment are collected in a separate tool, the KSC calendar.

What will change in 2027

The Act of 25 July 2025 provides for the new statutory authorization for the regulation to enter into force on 23 February 2027.^[2] The Ministry of Digital Affairs is working on draft RD313; its official description expressly states an intention to remove ISMS provisions from KRI because they are addressed in KSC.^[3]

As of 29 August 2026, organizations must not be audited against the draft as though it were law. The 2024 regulation remains in force and section 19 still requires an ISMS and an annual audit. The draft matters for future planning but cannot be presented as a current obligation.

Common mistakes

• Citing section 20 as the basis for the annual audit instead of section 19(2)(14).
• Treating ISO/IEC 27001 certification as mandatory.
• Restricting the audit to document review without sampling technical state and real practice.
• Hardware inventory without configuration information.
• Revoking access only when a person leaves, with no prompt reaction to duty changes.
• Logs that technically exist but are neither protected nor reviewed.
• No evidence of restore testing despite declared backups.
• Supplier agreements without security requirements proportionate to the service.
• No formal owner for corrective actions after the audit.
• Applying draft RD313 prematurely as if it were already law.

10 questions before a KRI audit

1. What is the precise legal basis for the entity being covered by the Digitization Act?
2. Which systems support performance of public tasks?
3. Does the inventory include hardware and software type and configuration?
4. Is risk analysis current and does it lead to concrete action?
5. Are access rights changed immediately after a role changes?
6. Does training match staff threats and responsibilities?
7. Can the organization detect unauthorized activity?
8. Do service contracts contain appropriate security requirements?
9. Are section 20 logs complete, protected and retained for the correct period?
10. Did the annual audit result in an action plan and verification of implementation?