What NBÚ Decree 227/2025 Requires for Identity and Access Management

Slovak operators of essential services have had a new rulebook for security measures since 1 September 2025. Decree No. 227/2025 Coll. of the National Security Authority (NBÚ) replaced Decree 362/2018 and turned the security measures into a table of 151 numbered items. Twelve of them, items 76 to 87, form the area called identity and access management (in Slovak, správa identít a prístupov).

The item with the most operational detail is item 80. At least once a year, the operator must review access accounts and access permissions, check that the approved permissions match the actual state of how they are exercised, detect unused accounts and invalidate them, and keep a record of the review at least from the end of the last audit to the end of the next audit or self-assessment.

Short answer: Decree 227/2025 expects you to manage every user and system account through its whole lifecycle with access-management technology, to review accounts and permissions at least annually, to invalidate unused accounts, and to keep a record of that review which an auditor can inspect. Which of the twelve items apply depends on whether you are a critical operator and whether the system is IT or operational technology.

This guide explains each of items 76 to 87, how to run and document the annual review, what changed from the previous decree and how the public-administration Decree 184/2026 relates. It is based on the official texts on Slov-Lex checked on 21 October 2026. It is practical guidance, not legal advice. Your legal scope, risk analysis and audit plan remain your organisation’s decisions.

How the decree fits into Slovak cyber security law

The obligation starts in Act No. 69/2018 Coll. on Cyber Security. Section 20(2) lists the areas in which security measures must be adopted, and letter (j) is správu identít a prístupov, identity and access management. Section 32(1)(b) authorises the NBÚ to set the content of the measures by decree, and Decree 227/2025 is that decree. Its Annex 3 states that it transposes the NIS 2 Directive, (EU) 2022/2555.

NIS 2 was transposed into the Act by Act No. 366/2024 Coll., effective 1 January 2025. Two later amendments followed, the most recent by Act 67/2026 Coll. On 21 October 2026, the latest consolidated version on Slov-Lex is the one effective from 30 April 2026, and the provisions quoted below come from that version.

Two timing rules in the Act matter for planning. Under § 19(1), an operator must adopt the measures within 12 months of its entry in the register of operators of essential services. Under § 29(1), it must verify their effectiveness through a cyber security audit within two years of registration; an operator that is not a critical operator may meet that first deadline by a self-assessment through the unified cyber security information system, in the manner set by § 29(8).

Who is an operator of essential services, and who is critical

The decree addresses the prevádzkovateľ základnej služby (PZS), the operator of essential services registered by the NBÚ under § 17 of the Act. The register covers, among others, central state bodies, critical entities, medium-sized and larger organisations active in the sectors of Annexes 1 and 2 of the Act, cities whose disruption could significantly affect public order, safety or health, and, since 30 April 2026, administrators of public-administration IT to which Category II or III measures apply.

Some operators are also a prevádzkovateľ kritickej základnej služby (PKZS), an operator of a critical essential service. Section 18 lists the critical services, and § 18(2) says that an operator performing at least one of them is a critical operator. Operators registered under the pre-2025 rules are treated as critical operators by the transitional § 34b(1), unless the NBÚ decides otherwise by 31 December 2026 under § 34b(2).

The same transitional section contains two options that run until 31 December 2026. Under § 34b(5), an operator treated as critical under § 34b(1) may, until that date, adopt and implement the security measures required by the rules effective from 1 January 2025 also by adopting and implementing the security measures under the rules effective until 31 December 2024; § 8 of Decree 227/2025 expressly states that § 34b(5) of the Act is not affected by it. Under § 34b(7), such an operator may, until the same date, carry out its audit under the rules effective until 31 December 2024. Our recommendation: if your organisation relies on either option, record that decision in the security documentation, because both options end with 2026.

For identity and access management, the distinction changes which items apply. Annex 1 of the decree marks every item for four columns: PZS and PKZS, each for information and communication technology (IKT) and for operational technology (OT). Several identity items apply only to some of those columns.

The Act adds two scope notes. Providers of the services listed in § 2(2), for example cloud computing, data centre and managed services, apply the security measures of Commission Implementing Regulation (EU) 2024/2690 under the last sentence of § 19(1). Operators within the scope of Regulation (EU) 2022/2554 (DORA) verify the effectiveness of their measures under that regulation, by a certified auditor (§ 29(9)). If either applies to you, confirm with your legal adviser which measures you follow.

Risk analysis decides the scope, and gaps must be justified

Annex 1 is applied through risk analysis. Section 3(2) of the decree says the scope of the general measures in Annex 1 “is determined on the basis of risk analysis”. Section 4(1)(f) requires the security documentation to record how the measures are adopted and carried out, including the justification for not adopting a measure, and § 5(1)(e) requires the risk management to state which measures are adopted and which are not, with the reasons. In our reading, an auditor can therefore ask for either evidence that an applicable item is implemented or a documented reason why it is not.

Items 76 to 87, mapped to controls and evidence

The table summarises each item in plain English, shows where the decree marks it as applicable, and suggests a practical control and the evidence to keep. The control and evidence columns are our recommendations. The decree prescribes outcomes and leaves the choice of tools to you.

Read the “Applies to” column carefully. Item 81 is not marked for non-critical operators in IT, and items 77, 86 and 87 are limited to OT or to critical operators. A risk analysis can still lead you to adopt them, because § 7(1) of the decree requires the measures to treat all risks identified in the risk analysis.

Five related items outside the identity section

Some requirements that identity and access teams own sit in other areas of Annex 1. All five below are marked for every column.

• Item 2 (organisation area) requires a designated person responsible for managing user access to the network and information systems, for granting and withdrawing access rights, keeping a register of them and keeping operational records of each access.
• Item 6 requires the principle of least privilege.
• Item 7 requires the principle of separation of responsibilities (zásada oddeľovania zodpovedností). The decree defines it narrowly: no user may modify or use the operator’s assets without authorisation or identity verification. It does not list incompatible combinations of permissions. Our recommendation is to define such combinations where your processes need them; the decree leaves that choice to you.
• Item 9 requires access to information on a need-to-know basis.
• Item 19 requires employees and third-party staff to return, demonstrably, all entrusted assets when their employment or contract changes or ends.

Item 64 (rules for assigning people to work roles) and item 73 (multi-factor authentication for remote access) also connect directly to the identity area.

Running the annual review required by item 80

Item 80 is one sentence. In our reading it combines four distinct tasks, and an auditor can examine each of them on its own, so we suggest planning them separately.

Set the scope before you collect data

The decree speaks of prístupové účty (access accounts) and prístupové oprávnenia (access permissions), and the item applies to both IT and OT for every operator. It does not list which systems must be included. In our reading, your risk analysis and asset register do that, because § 6 of the decree requires a centrally managed asset register that records asset owners.

Our recommendation is to include, for every system in scope:

• personal user accounts of employees and contractors;
• administrator and other privileged accounts;
• system and service accounts, because items 78 and 79 expressly cover systémové účty;
• accounts of third-party staff and suppliers.

Write the scope down with the review date and the reason any system was left out. A review that silently skips a system is hard to defend.

Compare what was approved with what exists

The decree asks you to verify “the consistency of approved permissions with the actual state of exercising the permissions”. That needs two data sets: the approved state and the actual state. The actual state comes from the target systems. The approved state comes from requests, approvals and role definitions. If approvals live in email or a ticket system without links to the permission, this step needs the most preparation.

For each account, the reviewer should be able to see who holds it, which permissions it carries, where each permission came from and when it was last used. Where any of those facts is missing, the review record should say so rather than fill the gap. A permission that nobody can trace to an approval is a finding in its own right.

Find and invalidate unused accounts

Item 80 requires “detection and subsequent invalidation of unused access accounts”. The decree does not define when an account counts as unused. Set the threshold yourself in your access policy, for example a number of days without a successful login per account type, and apply it consistently.

Last-login data is not available from every system, and some legitimate accounts are rarely used, such as emergency (break-glass) administrator accounts and service accounts for annual jobs. Treat these as exceptions with an owner and a reason, not as automatic deletions. For service accounts, confirm the dependency before you disable anything, because a business process may rely on it.

The previous decree required trvalé zablokovanie, permanent blocking. Decree 227/2025 uses zneplatnenie, invalidation. It does not say whether invalidation means disabling or deleting. Our recommendation is to disable first, record the date, and delete according to your retention rules, so the account history stays available for investigation.

Write the record and keep it long enough

The decree requires a record (záznam) of the review, kept “at least for the period from the end of the last audit to the end of the following audit or self-assessment”. The same retention formula appears in other items of Annex 1, for example item 28 on backup testing.

The audit rules come from Decree No. 493/2022 Coll., as amended by Decree No. 212/2026 Coll., effective 1 September 2026. Under the amended text:

• an audit ends when the final report is handed over to the operator, and may last at most 12 consecutive months (§ 2(5));
• an audit must be carried out and completed by the end of the third calendar year after the year in which the last audit ended (Annex 2, part B, point 1(a));
• a non-critical operator that uses self-assessment under § 29(8) of the Act carries it out every two years, and its audit deadline becomes the end of the fifth calendar year after the year in which the last audit ended (Annex 2, part B, points 1(b) and 3);
• an audit is also carried out after every significant change, within six months of the change having a significant effect on the implemented measures (Annex 2, part B, point 2);
• the self-assessment report must contain, among other things, a list of the evidence recorded (§ 2(6));
• an audit started and not completed by 31 August 2026 is completed under the previous rules, and an audit started by 31 December 2026 may still follow the previous rules (new § 3a).

A worked example, as our own reading of these rules: if your last audit ended in 2025 and no significant change triggers an earlier audit, the next audit must end by 31 December 2028 under point 1(a); a non-critical operator that self-assesses every two years has until 31 December 2030 under point 1(b). A review record made in 2026 then has to survive at least until that next audit ends. Because the decree says “audit or self-assessment”, a non-critical operator’s window could be read as closing earlier, at the next self-assessment. We recommend keeping each annual record at least until the next audit has ended, not only until the next self-assessment, since that is the reading with no gap. The transitional options of § 34b of the Act and § 3a of Decree 493/2022 can shift these dates for a particular operator, so check them against your own audit history.

In our recommendation, a useful record contains at least:

1. the review date and the person responsible (item 2 of Annex 1);
2. the scope: systems, account types and population, with documented exclusions;
3. the reviewers and what each reviewed;
4. each decision to keep or remove, with its date;
5. the unused-account threshold applied and the accounts found;
6. the outcome of every removal in the target system, including removals that failed or are still pending;
7. open items, their owners and deadlines.

What changed compared with Decree 362/2018

The access-control rules of the repealed Decree 362/2018 were in § 8(4). The comparison below quotes the version effective from 1 September 2023 and Annex 1 of Decree 227/2025.

The annual frequency and the comparison of approved permissions with the actual state were already in the old decree. For an organisation that already runs an annual review, the table points to the main changes: extend it to system accounts, check the OT and critical-operator columns, and set the retention period of the record. The transitional option in § 34b(5) of the Act, described above, allows an operator treated as critical under § 34b(1) to rely on the old measures only until 31 December 2026.

Public administration and MIRRI Decree 184/2026

Administrators of public-administration IT (informačné technológie verejnej správy, ITVS) have a second set of rules. Decree No. 184/2026 Coll. of the Ministry of Investments, Regional Development and Informatization (MIRRI) was adopted on 1 July 2026 and takes effect on 1 January 2027. It repeals Decree 179/2020 (§ 6) and divides the minimum security measures into Categories I, II and III (§ 1(2)). The categories are cumulative: § 1(4) lists the bodies to which Category I applies, § 1(5) those to which Categories I and II apply, and § 1(6) those to which all three apply.

The legend of its Annex 2 defines two abbreviations: ITVS (informačná technológia verejnej správy, public-administration information technology) and ISVS (informačný systém verejnej správy, public-administration information system). Its identity and access area is items 99 to 111 of Annex 2. Items 99 to 101 are marked for all three categories, and items 102 to 111 for Categories II and III. Three items stand out:

• Item 99 requires a defined, implemented and controlled system of identity and access management for all ISVS and ITVS, including a list of systems, the types of identities, technical accounts and administrators, and the authentication methods.
• Item 101 requires the administrator to determine, implement and use mechanisms and tools for identity and access management for all ISVS and ITVS.
• Item 105 repeats the content of item 80 of Decree 227/2025: the review at least once a year, the detection and invalidation of unused accounts, and the record kept at least from the end of the last audit to the end of the next audit or self-assessment. The two items differ only in minor phrasing.

Section 5(1) gives a transitional period: until 30 June 2027, the minimum measures of the category that applies to the body count as adopted if the minimum measures of that category under Annex 2 of Decree 179/2020, in the version effective until 31 December 2026, have been adopted.

The two regimes overlap for some public bodies. Since 30 April 2026, § 17(1)(g) of Act 69/2018 lists ITVS administrators to which Category II or III measures apply among the persons registered as operators of essential services; the footnote to that provision currently refers to the categories under § 3(3) and (4) of Decree 179/2020. Such an organisation can face both decrees. Neither decree states how an organisation subject to both should combine the two sets of measures in one set of documentation, so confirm the approach with the NBÚ and MIRRI. Because the annual review has the same content in both, our recommendation is to design one review whose scope and record satisfy both texts.

Where IGA supports these measures

Identity governance and administration (IGA) is software that manages who has access to which applications, who approved it, and whether it is still needed. It supports items 78 and 80 most directly and contributes to items 76, 81 and 82. The decree does not name a product category, so an IGA tool is one way to meet these items, not a legal requirement in itself.

easyIGA is a business-facing IGA layer built on the open source midPoint platform. For the measures above, this is what it does today:

• Requests and approvals: employees request access by its business name, and the person responsible approves it with the configured policy results beside the request. easyIGA records the requester and the captured approval steps, which gives you the approved state that item 80 compares against.
• Lifecycle through midPoint: midPoint connects authoritative identity data with configured policies and target systems, so joiners, movers and leavers are handled through configured integrations (item 78). easyIGA adds the readable requests, decisions and reviews.
• Access reviews: the reviewer sees the person and the access under review with last use, granted by and approved by, when the connected systems and captured approval history provide them. Keep and remove are both recorded decisions. See access reviews.
• Removals followed to the result: easyIGA distinguishes verified, pending, failed and unknown outcomes, so a removal decided in the review is not counted as done until the target system confirms it.
• Missing history stays visible: a direct grant with no matching easyIGA request is marked as granted outside easyIGA, with the creation account, channel and time recorded by midPoint. Missing approval steps stay marked as missing instead of being reconstructed.
• Accounts without an owner: comparing accounts in connected systems with identity records shows ownership gaps, including for service accounts. In our reading, that supports the item 80 review, in which an account with no responsible owner is a finding to resolve. The available view depends on the account type, the connected source and the supported workflow, which our team confirms with you. See orphaned accounts and non-human identities.
• Conflicting access: easyIGA shows the result of midPoint’s configured exclusion policies on the approval card, so the approver sees a known conflict before deciding. Creating and simulating these rules inside easyIGA is planned, not available today. See separation of duties.
• Evidence: review evidence exports include the available request and approval history. See audit evidence.

Deployment is self-hosted by default, on your infrastructure and in your jurisdiction, with an EU-hosted deployment operated by our team available on request (deployment options).

What IGA does not do for Decree 227/2025

An IGA tool covers part of the identity area. Plan the rest explicitly.

• Authentication. Items 84 and 85, and multi-factor authentication for remote access under item 73, belong to your identity provider, your applications and your user rules. An approval in easyIGA does not prove that multi-factor authentication was used.
• Recording every use of a permission. Item 76 asks for technologies that record the use of access permissions, and item 2 asks for operational records of each access. Application, authentication and network logs provide that. easyIGA displays last use only when a connected system supplies it, and an access record does not show every action performed inside an application.
• OT-specific controls. Items 77, 86 and 87 need OT access technology, monitoring and wireless detection.
• Privileged session control. Item 82 can be governed at the level of who receives privileged roles. Controlling or recording privileged sessions needs separate tools.
• Your thresholds and decisions. The tool applies the policy you define. The unused-account threshold, the review scope and the retention period are decisions for your documentation.
• Compliance itself. A product does not establish compliance. A certified cyber security auditor, or your cyber security manager in a self-assessment, judges whether the measures are effective. The quality of any review also depends on the source data: a wrong manager or a missing end date in the source records will not be fixed by a better review screen.

Checklist before your next audit or self-assessment

1. Confirm your status in the register: PZS, PKZS, or also an ITVS administrator under Decree 184/2026.
2. For each of items 76 to 87, record whether it applies (IKT or OT, PZS or PKZS), whether it is adopted, and the documented justification where it is not.
3. Designate the person responsible for user access under item 2.
4. List systems in scope, with owners, from the asset register.
5. Include system and service accounts, each with a named owner and purpose.
6. Define the unused-account threshold per account type and the exception process.
7. Make the approved state traceable: requests, approvals and role definitions linked to permissions.
8. Run the review at least once every 12 months and follow each removal to a confirmed result in the target system.
9. Write the record with the seven elements listed above.
10. Set retention so each record survives at least until the next audit has ended.
11. Check the record format against what the self-assessment report must list as evidence.
12. Assign owners for authentication, logging and OT controls that sit outside IGA.

Frequently asked questions

Does item 80 apply to operators that are not critical?

Yes. Annex 1 marks item 80 as applicable for both the operator of essential services and the operator of a critical essential service, for IT as well as OT.

Is a yearly review enough?

The decree sets a minimum of once a year. A more frequent cycle for privileged or high-risk access is a decision for your risk analysis, and the decree does not prescribe it.

Must service and system accounts be reviewed?

Item 80 refers to access accounts without listing types, while items 78 and 79 expressly include system accounts in lifecycle management and unique identification. We recommend including them, each with an owner who can confirm its purpose.

What exactly is an unused account?

The decree does not define it. Set a measurable threshold in your access policy, apply it consistently and document exceptions such as emergency accounts.

How long must the review record be kept?

At least from the end of the last audit to the end of the next audit or self-assessment. Under Decree 493/2022 as amended by Decree 212/2026, the next audit must be completed by the end of the third calendar year after the year in which the last audit ended, or the fifth calendar year for a non-critical operator that self-assesses every two years, and within six months after a significant change.

Does the decree require an IGA product?

No product is named. Item 76 requires technologies for managing access permissions, and item 101 of Decree 184/2026 requires mechanisms and tools for identity and access management. An IGA tool is one way to provide them.

We are a public body. Which decree applies?

It depends on your registration and category. Decree 184/2026 governs ITVS security measures from 1 January 2027, with a transition until 30 June 2027. If you are also registered as an operator of essential services, Decree 227/2025 applies as well. Confirm the combination with the NBÚ and MIRRI.

For the wider NIS 2 picture, see What NIS2 actually requires and what it does not and our NIS2 access-control overview. For the leaver side of item 78, read How to remove employee access completely and prove it.

Sources and verification record

All sources were checked on 21 October 2026. Slov-Lex states that its HTML text is informative and that the PDF version is legally binding. Item wording and the applicability columns in this article were checked against the PDFs. On 21 October 2026 the Slov-Lex version history showed no amendment of Decree 227/2025 and no version of Act 69/2018 later than the one effective from 30 April 2026.

• Národný bezpečnostný úrad: Vyhláška č. 227/2025 Z. z. o bezpečnostných opatreniach, adopted 26 August 2025, published 28 August 2025, effective 1 September 2025. Official PDF; Annex 1 PDF. Used: §§ 3, 4, 5, 6, 7, 8, 9, 10, 11; Annex 1 items 2, 6, 7, 9, 19, 28, 64, 73 and 76 to 87; Annex 3.
• Národná rada Slovenskej republiky: Zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti, consolidated version effective from 30 April 2026. Used: §§ 2, 17, 18, 19, 20, 29, 32, 34b.
• Národná rada Slovenskej republiky: Zákon č. 366/2024 Z. z., published 19 December 2024, effective 1 January 2025.
• Národná rada Slovenskej republiky: Zákon č. 67/2026 Z. z., published 30 April 2026. Used: Čl. III (amendment of § 17(1)(g) of Act 69/2018) and Čl. IV.
• Národný bezpečnostný úrad: Vyhláška č. 362/2018 Z. z., version effective from 1 September 2023, repealed on 1 September 2025. Used: § 8(4); Annex 3.
• Národný bezpečnostný úrad: Vyhláška č. 493/2022 Z. z. o audite kybernetickej bezpečnosti, version effective from 1 September 2026. Used: § 2(5) and (6), § 3a, Annex 2 part B.
• Národný bezpečnostný úrad: Vyhláška č. 212/2026 Z. z., adopted 21 August 2026, published 27 August 2026, effective 1 September 2026. Used: new § 2(5) and (6), § 3a, Annex 2 part B.
• Ministerstvo investícií, regionálneho rozvoja a informatizácie SR: Vyhláška č. 184/2026 Z. z., adopted 1 July 2026, published 9 July 2026, effective 1 January 2027. Annex 2 PDF. Used: §§ 1, 5, 6, 7; Annex 2 items 99 to 111.