KRI in 2026: the Polish national interoperability framework, § 19 and the annual audit

What KRI is: the structure of the regulation

The full name is the Council of Ministers regulation of 21 May 2024 on the National Interoperability Framework, the minimum requirements for public registers and the exchange of information in electronic form, and the minimum requirements for ICT systems ^[1]. It is an implementing act to the act of 17 February 2005 on the informatisation of the activity of entities performing public tasks ^[2], which matters in practice: it is the act, not the regulation, that determines who is subject to the obligations.

The regulation runs to twenty-one paragraphs in five chapters. Chapter one (§§ 1-2) contains the scope and definitions. Chapter two (§§ 3-9) describes interoperability itself in three dimensions: organisational, meaning alignment of processes between offices; semantic, meaning shared vocabularies and data structures; and technical, meaning protocols and formats. Chapter three (§§ 10-14) governs public registers and data exchange between them. Chapter four (§§ 15-20) concerns ICT systems and contains the core of the security requirements: § 19 establishes the management system duty and § 20 governs system logs. Chapter five is a single final provision on entry into force.

The numbering matters more than it might seem. In the 2012 regulation the management system duty sat in § 20 and system logs in § 21. In the 2024 act both provisions moved up by one. Documentation copied from older templates that cites "§ 20 of KRI" in the context of an information security management system today points at the provision on logs, not on the management system. Auditors and inspectors notice this, because it shows documents were transcribed rather than read.

History and amendments

The Council of Ministers adopted the first KRI regulation on 12 April 2012; it was published on 16 May 2012 in Journal of Laws 2012 item 526 and later consolidated as Journal of Laws 2017 item 2247. It entered into force on 31 May 2012 and applied for twelve years, until on 21 May 2024 the Council of Ministers adopted a new act (Journal of Laws 2024 item 773), which repealed and replaced its predecessor with effect from 23 May 2024.

The change was mainly tidying-up. References to standards were updated, the wording aligned with data protection law and the national cybersecurity system act, and the whole act renumbered. The substance of the security duty - an information security management system, fourteen detailed actions and an audit at least once a year - passed into the 2024 version practically unchanged. If policies, procedures or audit reports still cite Journal of Laws 2012 item 526 or the 2017 consolidated text, they need updating, even though the substantive requirements are the same.

Who KRI covers: entities performing public tasks

The scope of KRI is set by the informatisation act ^[2], which uses the notion of an entity performing public tasks. It covers central government bodies together with central, regional and agency offices, local authorities at all three levels and their organisational units: public schools and kindergartens, libraries, cultural centres, social welfare centres and municipal undertakings. It also covers state funds and insurance institutions, the judiciary and prosecution services, and specialised supervisory and inspection offices.

The criterion is functional, not formal. What decides is not the legal form of the entity but whether it performs a public task. A commercial company or a private kindergarten funded solely from fees therefore stays outside KRI, while the same private entity is covered in respect of a specific public task it performs - one funded from a public grant, say. That is no exemption from other duties: data protection law ^[7] and sectoral rules apply regardless.

The scale is considerable. According to Central Statistical Office data as at 1 January 2025 Poland has 2,479 municipalities, 314 counties, including 66 cities with county rights, and 16 voivodeships. To that add central government bodies, courts and prosecution services, and the tens of thousands of schools and educational establishments that are organisational units of local authorities. In total that means tens of thousands of entities - an order of magnitude more than under the national cybersecurity system act ^[6], which covers a narrower, statutorily designated group.

§ 19 of KRI: the management system duty

Paragraph 19(1) requires an entity performing public tasks to "develop and establish, implement and operate, monitor and review, and maintain and improve an information security management system". The wording is not accidental: it reproduces the Deming cycle, also known as plan-do-check-act, on which the ISO/IEC 27000 series is built. The legislator therefore requires not a one-off deployment of controls but a process maintained over time.

The same provision states what the management system is to ensure. It names the classic triad of information security objectives - confidentiality, availability and integrity - and then extends it with four further attributes: authenticity, accountability, non-repudiation and reliability. That extension is characteristic of administrative regulation and follows from the nature of an official document. In private dealings it is usually enough that data is accurate and available; in administration you additionally have to show who did what and when, and to make later denial of that fact impossible.

The presumption of conformity with ISO 27001

The greatest practical weight sits in § 19(3). It provides that the requirements of subsections 1 and 2 are treated as met where the management system was developed on the basis of the Polish Standard PN-ISO/IEC 27001, and where establishing controls, managing risk and auditing are done on the basis of the standards associated with it, the regulation naming two outright: PN-ISO/IEC 27002 ^[4] for establishing controls (see the ISO 27002 article) and PN-ISO/IEC 27005 ^[10] for risk management. Note that the 2012 version also referred to PN-ISO/IEC 24762 on disaster recovery; that reference is gone from the 2024 act.

The presumption gives units a clear path, but it is often over-read. The regulation speaks of developing a management system on the basis of a standard, not of obtaining a certificate. Most Polish local authorities are not certified to ISO 27001 and do not need to be - they build documentation, policies and procedures following the structure of the standard, which is enough to rely on the presumption. Nor does the relationship work automatically in the other direction, as discussed below.

The fourteen actions in § 19(2)

Paragraph 19(2) states that information security management is delivered in particular by management ensuring the conditions for carrying out and enforcing fourteen actions. The construction matters: the addressee is the management of the entity, not the IT department, and it is management that answers for creating conditions in which those actions are possible at all. The phrase "in particular" in turn means the list is not closed.

The first five points cover foundations. Point 1 requires updating internal rules as the environment changes, which in practice means a security policy eight years old does not meet the requirement even if it is formally in force. Point 2 requires maintaining a current inventory of hardware and software together with type and configuration - without it none of the other requirements can be demonstrated, because there is no telling what they apply to. Point 3 requires periodic risk analyses of loss of integrity, availability or confidentiality and action following from their results; the method is set out in PN-ISO/IEC 27005, cited in the regulation. Points 4 and 5 form a pair: the first requires people processing information to have rights appropriate to their tasks, the second that rights be changed without delay when duties change. The second is the one most often unmet in inspections, because procedures usually describe granting access and say nothing about removing it.

Point 6 concerns training and is the only one to state the subjects it must cover: information security threats, the consequences of breaching the rules including legal liability, and the use of measures minimising human error. The regulation sets no frequency, which is sometimes mistaken for the absence of an obligation (see the security awareness article). Point 7 requires protecting information against theft, unauthorised access, damage and disruption, and breaks that goal into three components: monitoring access to information, activity aimed at detecting unauthorised action, and measures preventing unauthorised access at the level of operating systems, network services and applications. The second - active detection - is a commitment to act, not merely to hold controls; in larger units it is delivered through central collection and correlation of events, described in the literature as the function of a security operations centre ^[12].

The following points move from organisation to specifics. Point 8 requires rules for secure mobile and remote work, point 9 protection of information against unauthorised disclosure, modification, removal or destruction, point 10 clauses in service contracts with third parties guaranteeing an adequate level of security, and point 11 rules for handling information that minimise the risk of theft of information and of the means of processing it, including mobile devices.

Point 12 is the largest and comprises eight elements of ICT system security: care for software updates, minimising the risk of information loss through failure, protection against errors, loss and unauthorised modification, use of cryptographic mechanisms proportionate to threats or legal requirements, security of system files, reduction of risks arising from published vulnerabilities, prompt action on noticing not yet disclosed vulnerabilities, and checking systems for conformity with standards and security policies. The last refers directly to hardening practice based on recognised configuration baselines such as the CIS Benchmarks ^[13] (see the hardening article).

The final two points close the cycle. Point 13 requires prompt reporting of incidents in a predetermined way allowing corrective action to be taken quickly; the principles and stages of such a process are set out in ISO/IEC 27035-1:2023 ^[11]. Point 14 requires a periodic internal information security audit, at least once a year. It is the only requirement on the whole list carrying a specific deadline, and for that reason it is the first item in every inspection.

Paragraph 19(4) adds that, independently of those fourteen actions, additional controls are to be established wherever the risk analysis for ICT systems justifies it. The list in subsection 2 is therefore a floor, not a ceiling.

The KRI audit: once a year

The audit is the most easily verified KRI obligation, because either a report from the last twelve months exists or it does not. The regulation speaks of an internal audit, which does not mean it has to be performed by an employee. In larger units, such as regional government offices or ministries, internal audit departments run it; in smaller local authorities, contracting the internal audit out is a common and permissible practice. What matters is that the auditor does not assess their own work - more on that in the section on mistakes. The audit programme, sampling and auditor requirements are set out in ISO 19011:2026 ^[9], which contains guidance rather than requirements and does not itself create an obligation. The detailed course of the work is described in a separate article on the KRI audit.

The scope of the audit follows from § 19. It covers the management system documentation - the security policy, procedures, risk analysis and continuity plans - and verification of technical measures by sampling configurations: multi-factor authentication, encryption, backups, event logging and malware protection. Operational evidence matters just as much - incident registers, restore test records, training attendance lists, previous audit reports - because that is what distinguishes a procedure in use from a procedure on paper. Some auditors add interviews with randomly chosen staff and technical tests such as vulnerability scanning or penetration testing; the regulation does not require them, but they are the simplest way of checking whether the declared controls work.

The audit report should describe the objectives and scope, the method adopted, the nonconformities found together with their severity, the recommendations and a remediation plan naming people and deadlines. It goes to the head of the unit and can be demanded by an external inspection. The report alone, without a plan of action, does not discharge the obligation, because § 19(2)(3) requires action to be taken in line with the results of the analyses.

The regulation does not set auditor qualifications. The market has come to expect a CISA certification or ISO 27001 lead auditor credentials, several years of security audit experience, preferably in the public sector, and independence from the team that implemented the solutions under examination. Cost depends chiefly on the size of the unit and the complexity of the environment: in a small municipality an audit usually comes in under twenty thousand zloty, in a large city or regional office it reaches several tens of thousands, and in a ministry or central office it can exceed a hundred thousand. These are market observations, not rates set by the rules.

Inspections by the audit office and regional chambers

KRI provides no financial penalties, and that distinguishes it fundamentally from data protection law or the national cybersecurity system act. That does not mean there are no consequences - they are spread across several parallel oversight mechanisms.

The supreme audit office regularly examines the state of informatisation and ICT security in public units ^[5]. A recurring theme in its findings is documentation diverging from practice: security policies formally exist but are out of date or unknown to staff, risk analyses go undocumented, and audits happen late or not at all. A negative assessment leads to a post-inspection statement with recommendations and deadlines, publication of the findings in a public report and, where a breach of law is suspected, notification of the prosecuting authorities.

Regional audit chambers examine the financial management of local authorities and touch KRI indirectly, examining the justification for IT spending and the correctness of accounting for digitisation projects. That matters particularly with EU funds, where conformity with KRI requirements can be a condition of eligibility. The Ministry of Digital Affairs may in turn inspect central government units and issue recommendations.

Responsibility for organising security rests with the head of the unit. It can take the form of disciplinary liability for breaching official duties or civil liability for loss caused by neglect. In extreme cases criminal liability comes into play - the criminal code provides in article 165 § 1(4) for the offence of causing danger to the life or health of many people or to property on a large scale by disrupting the automatic processing, storage or transmission of computer data, and in article 268 for obstructing an authorised person's access to information.

The most measurable consequences, though, come from data protection law ^[7], because every local authority is a controller of residents' personal data. A breach leading to a leak triggers a duty to notify the supervisory authority within 72 hours, often a duty to inform the individuals concerned, and opens the way to civil claims. One Polish specificity is worth knowing: article 102 of the act of 10 May 2018 on the protection of personal data caps the administrative fine for public finance sector bodies at PLN 100,000, and at PLN 10,000 for state and local cultural institutions. The upper limits of article 83 of the GDPR - EUR 20 million or 4 per cent of turnover - do not apply to those entities, which is a frequent source of confusion in training material aimed at local government.

The relationship with PN-ISO/IEC 27001 and 27002

The presumption in § 19(3) makes ISO/IEC 27001 ^[3] the natural point of reference when implementing KRI (see the ISO 27001 article). The standard has two parts of different character. Clauses four to ten contain management requirements - the context of the organisation, leadership, planning, support, operation, performance evaluation and improvement. Annex A in turn lists 93 controls in four groups: organisational, people, physical and technological. Their detailed description with implementation guidance is in ISO/IEC 27002:2022 ^[4].

The mapping works well, because both constructions grow from the same tradition. The inventory in point 2 corresponds to control A.5.9 on the inventory of information and associated assets. The permissions in points 4 and 5 are covered by A.5.15, A.5.16 and A.5.18 on access control, identity management and access rights. Training in point 6 corresponds to A.6.3. Cryptography in point 12(d) has its counterpart in A.8.24, and incident reporting in point 13 in the A.5.24 to A.5.27 group covering response planning, event assessment, response and lessons learned. The audit in point 14 aligns with clause 9.2 of the standard, which requires internal audits at planned intervals.

Convergence is not identity, though, and the conclusions to draw are cautious. An ISO/IEC 27001 certificate does not equate to full conformity with KRI. Paragraph 19(3) gives a presumption that the requirements of subsections 1 and 2 are met, but only where the scope of the implemented management system actually covers the systems used to perform public tasks. A certificate issued for a narrow scope - one data centre, say - does not extend that presumption across the whole unit. Regardless of certification, the annual audit duty in point 14 remains, and the three-year certification cycle with surveillance audits does not replace it.

For that reason most units take the second path: implementing a management system based on the standard, without accredited certification. It is cheaper to maintain and sufficient for KRI. Full certification makes sense where a unit needs confirmation towards third parties - in tender procedures, in international cooperation or when performing work for the private sector.

KRI, the KSC act and NIS2: three different regimes

These three are often confused, though they differ in scope, in the weight of the obligations and in the sanctions. KRI covers all entities performing public tasks, requires a management system and an annual audit, and is enforced through audit office inspections and management responsibility, with no financial penalties. The national cybersecurity system act ^[6] covers a narrower group of essential and important entities listed in its annexes, imposes incident reporting duties within strict deadlines and provides for substantial financial penalties. The NIS2 directive ^[8] does not apply directly in Poland - its content entered national law through the amendment to the KSC act, in force since 3 April 2026 (Journal of Laws 2026 item 252). This is covered more fully in the KSC article and the NIS2 article.

The qualification criterion for local authorities is crucial and often stated wrongly. A municipal office becomes an essential entity if it employs at least 50 people in full-time equivalent terms on employment contracts, as at 1 January of the given year. That follows from annex 1 to the amended act, sector "Public entities", point 4. It is not a population threshold - the number of residents is irrelevant here. Nor is it an exemption threshold: a smaller office simply does not qualify as an essential entity on that basis, but it may still be covered as an important entity or through its organisational units, such as a hospital, waterworks or municipal undertaking.

In practice the regimes overlap. Every municipal office is subject to KRI regardless of size. Voivodeship offices, regional government offices and ministries are subject to both. A public school is subject to KRI as an organisational unit of a local authority but usually does not qualify in its own right under the KSC act; in most local authorities the KRI duties for schools are discharged centrally at the level of the municipal or county office. The good news is that implementations can be shared: a management system built to ISO 27001 satisfies KRI and a large part of the KSC act at once, and the remaining differences come down mainly to incident reporting deadlines and the extent of documentation.

Implementing KRI from scratch

In a unit with no management system, a typical implementation project takes six to twelve months and runs through several stages of different character. It starts with a baseline audit, usually a month or two: establish what already exists, map the actual state onto the fourteen actions of § 19(2), and produce a list of gaps. This stage often reveals that the unit meets more requirements than it thought, only without documentation to prove it.

The next two to three months go on the documentation layer: an information security policy approved by the head of the unit, operating procedures covering incident management, backups and access, a documented risk analysis with a treatment plan, and a business continuity plan. For a medium-sized municipality that usually means several dozen documents, though their number matters less than whether they match reality.

The longest stage is technical, taking three to six months. It covers hardening of workstations and servers (see the hardening article), multi-factor authentication for remote access and privileged accounts, malware protection, backups with a documented restore test, central log collection, and encryption of media and databases holding personal data. The training layer starts in parallel and, unlike the others, has no end date (see the security awareness article). The first compliance audit with a corrective action plan closes the project.

Costs depend on scale and on how much the unit already has. In a medium municipality of a few thousand residents and a few dozen workstations, the first year usually falls between several tens and a little over a hundred thousand zloty, including consulting, technical investment and the audit. In later years the cost drops to licences, training and the annual audit. In a unit serving tens of thousands of residents with several hundred workstations, first-year outlay is several times higher. These are market estimates, not rates set by the rules.

The commonest mistakes in public sector units

Audit office findings ^[5] and experience from KRI audits point to a recurring pattern. The commonest mistake is documentation created independently of the organisation it describes. A security policy is often a template downloaded from the internet that staff have never read and that describes processes the unit does not have. The risk analysis either does not exist or dates from several years ago and was not updated after significant changes, even though point 3 speaks of periodic analyses and point 1 of updating rules as the environment changes.

The second pattern is controls nobody has tested. Continuity plans exist but have never been exercised. Backups are taken but never restored, so the unit learns they are incomplete or corrupt only during an outage or a ransomware attack. Logs are collected but nobody reviews them, and their retention is often shorter than the time needed to detect an incident - which defeats both point 7(b) and the evidential value of the records required by § 20.

The third pattern concerns access. Multi-factor authentication is still not standard for remote access, and administrative accounts are used for everyday work including email and web browsing. Accounts of people who changed roles or left remain active, even though point 5 requires rights to be changed without delay. On top of that sits a technical layer neglected for years: systems out of vendor support, default passwords on network devices, unnecessary services enabled, and no inventory that would make any of it visible.

Conflict of interest in the audit deserves separate mention. Commissioning the KRI audit from the firm that implemented the solutions under examination is a common and, on cost grounds, understandable practice, but it produces a report confirming the quality of its own author's work. Formally the obligation is met; in fact the audit loses the function it was created for. The principle of auditor independence is set out in ISO 19011:2026 ^[9], cited above.

A practical checklist for testing a unit's readiness has ten items: a security policy approved and known to staff; a current risk analysis with an asset map and treatment plan; a complete inventory of hardware and software with update status; implemented rules for handling and labelling information; a tested incident reporting procedure; backups with a documented restore test; multi-factor authentication for remote access and privileged accounts; documented hardening of workstations and servers based on recognised benchmarks; documented staff training; and a KRI audit report from the last twelve months together with a corrective action plan (see the KRI audit article). The absence of any of those the auditor has to record as a nonconformity.