Information Security in the Banking System of Ukraine (NBU Regulation No. 95)
This guide is part of the documentation available in SecBoard. It summarises the Regulation on the organization of measures to ensure information security in the banking system of Ukraine, approved by the Resolution of the Board of the National Bank of Ukraine of 28 September 2017 No. 95 (the Regulation / Положення). It explains scope, structure, and how SecBoard modules help banks (and, where applicable, non-bank participants of NBU information systems) implement and demonstrate compliance. Use SecBoard Framework Compliance with a Custom or Local framework to map controls and evidence; use other SecBoard modules for risk, assets, access, logging, incidents, policies, training, and cryptography.
What is the Regulation (No. 95)?
The Regulation establishes requirements for information security and cyber protection for banks in Ukraine. It is based on the Law on the NBU, the Law on Banks and Banking Activity, the Law on Information Protection in Information and Telecommunication Systems, the Law on National Security, presidential decrees on cybersecurity, and national standards DSTU ISO/IEC 27000:2015, DSTU ISO/IEC 27001:2015, and DSTU ISO/IEC 27002:2015. It does not set requirements for physical security of bank premises (covered by other NBU acts), use of NBU cryptographic means in NBU systems, or cloud technologies (to be defined separately).
Scope: The Regulation applies to banks. Requirements of Section III (cryptographic protection in NBU information systems) also apply to non-bank institutions that are participants in NBU information systems. Banks must implement an information security management system (ISMS) in accordance with DSTU ISO/IEC 27001:2015 for a defined scope, using a risk-based approach and implementing Annex A controls (per DSTU ISO/IEC 27002:2015) plus the mandatory measures in Sections IV and V. The minimum scope of the ISMS must include all critical business processes of the bank. The NBU may verify the state of implementation of the ISMS and fulfilment of the Regulation’s requirements.
Structure of the Regulation
The Regulation has five sections. Section V took effect on 1 September 2019; the rest from 1 March 2018.
Definitions (e.g. multi-factor authentication, malicious code, critical business processes, bank network, minimal privileges, UTM, risk-based approach). Principles of information security; principles of cryptographic protection for NBU systems (TLS, etc.). ISMS per DSTU ISO 27001:2015; risk management process; Annex A + Sections IV, V; minimum scope = critical business processes; NBU right to inspect.
Governing body for ISMS; composition (chair, CISO/deputy, owners of critical processes, risk head); tasks (policy, SoA, strategy, projects, resources, awareness, monitoring). Information security policy (objectives, scope, principles, roles); review at least yearly; communicate to staff. Strategy; business continuity plan; document structure.
Participants configure crypto per NBU documentation. Bank must protect its systems from unauthorized access and DoS per Section IV.
CISO (deputy chair level); security unit (≥2 staff); segregation of duties; staff awareness, contracts, internal docs, training; removable media; access control (docs, minimal privileges, no dev/admin/ops combination, MFA for admin, account lock, logging 3y/1y); crypto policy and key management; cabling and SKS; anti-malware (centralized, email/internet/media check, incident process); OS and application software; update process; DBMS; network (segmentation, documentation, change control, device ID, no default accounts, no IPv6/SNMPv1–2); wireless; remote access (DMZ, MFA); perimeter; incident management (process, detection, notification, classification, response, analysis, storage ≥1 year); fax/MFD/phones; email; secure development and operations; decommissioning.
No unencrypted radio; removable media list and automated control; centralized account management; centralized security updates; automated incident management; PFS for TLS; cable marking (ANSI/TIA/EIA-606); combined anti-malware; OWASP for web apps; encrypt DB–app; server separation; jump server; MFA for ISMS access; IDS/IPS; DoS/DDoS protection; certificates from accredited/registered CA for NBU interaction.
Key requirement areas (Sections IV and V)
| Area | Requirements (summary) |
|---|---|
| Governance & ISMS | Governing body; policy (yearly review); strategy; BCP; CISO (deputy chair); security unit ≥2; segregation (security vs dev/admin/ops; IT not owner of banking systems). |
| Risk management | Risk management process; risk-based approach; Annex A + IV, V. |
| Access control | Internal docs (identification, authentication, authorization; minimal privileges; periodic review); no single role combining dev/admin, dev/ops, admin/ops, operations/control; MFA for admin/support; lock after 5 failed attempts, 90 days inactivity, dismissal; log access grant/revoke/change (≥3 years), access events (≥1 year). |
| Cryptography | Crypto policy; key management (generation, distribution, storage, replacement, compromise, revocation, recovery, backup, destruction, audit); approved algorithms and key sizes; TLS; IPsec if no TLS; PFS (Section V). |
| Logging & monitoring | Log access management and access events; retain per Regulation; protect logs. Centralized monitoring (Section V). |
| Malicious code | Policy; current supported anti-malware; centralized management; check email, internet, removable media; incident process; logs ≥3 months; combination of means (Section V). |
| Network & perimeter | Segmentation, firewalls, documentation, change control, device ID, disable unused ports, no default accounts, no IPv6, SNMP; wireless in separate segment, WPA2-Enterprise; remote access (DMZ, MFA); DMZ for client-facing; IDS/IPS, DoS/DDoS (Section V); penetration tests. |
| Incident management | Process and documents: detection, notification, classification, response, analysis, storage (≥1 year); roles; automate (Section V). |
| Removable media | Policy; identification; list; automated control (Section V). |
| Secure development & ops | Security requirements; test environment; documentation; control of measures, vulnerabilities, config; recovery; decommissioning; OWASP (Section V). |
How SecBoard modules support the Regulation (No. 95)
SecBoard helps you document scope, map requirements to controls, collect evidence, and track status. Use the modules below in line with your bank’s ISMS scope and NBU expectations.
| SecBoard module | Regulation area | How it helps |
|---|---|---|
| Framework Compliance | All sections | Create a Custom or Local framework (e.g. “NBU 95 – Information security in the banking system”). Map control categories and controls to Sections I–V and key paragraphs. Attach evidence, assign owners, track review. Use for gap analysis and NBU inspection readiness. Dashboard and Cabinet traffic light show status. |
| Risk Assessment (app_risk) | п. 10–11 (risk management) | Document information security risk assessment and treatment within the bank’s risk management system. Link risks to controls. Use for risk-based approach and Annex A. Evidence for Framework Compliance. |
| Incident Register (app_incident) | п. 130–132 (incident management) | Record and manage information security incidents. Document detection, notification, classification, response, and analysis. Support storage of incident information (≥1 year). Use for incident process and NBU inspection evidence. Link to Framework Compliance. |
| Asset management (app_asset) | п. 75, 113 (inventory) | Maintain inventory of software (п. 75) and of fax/MFD devices (п. 113). Support critical business processes and asset scope for ISMS. Asset Guide available. |
| Keys & Certificates (app_keycert) | п. 44–56, 150 (crypto, keys, certs) | Manage cryptographic keys and certificates (generation, storage, lifecycle, revocation). Support crypto policy and key management documentation (п. 44–45). Evidence for NBU interaction certificates (п. 150). Key/Cert Guide available. |
| Document Register / Legislative docs (app_doc) | п. 17–22, 34–36, 61, 112, 117 (policies) | Store and version ISMS documents: policy, strategy, BCP, internal documents (access, removable media, anti-malware, fax/MFD/phones, email). Link to Framework Compliance. Legislative docs for official Regulation text. Mandatory Processes for recurring controls. |
| Cabinet (app_cabinet) | п. 36–41, 83–88 (access, roles) | Manage users, groups, roles, and permissions; support minimal privileges and periodic access review. Document privileged accounts and access model. Cabinet Users Guide and Org Structure support governance and CISO/security unit documentation. |
| SOC / Wazuh (app_soc) | п. 42–43, 127 (logging, monitoring) | Centralise logs and monitor access and config changes. Use for logging and access-event evidence (п. 42–43) and for control of security measures and vulnerabilities (п. 127). FIM Dashboard Guide available. Attach reports in Framework Compliance. |
| Gophish (app_gophish) | п. 33 (awareness) | Phishing simulations and awareness. Support security awareness program (п. 33). Gophish Guide available. |
| Study / Training (app_study) | п. 30–33 (awareness, training) | Deliver and track security awareness and training. Use for staff awareness (п. 30–33) and training records. Supports governance evidence. |
| Access (app_access) | п. 36–41 (access control) | Manage application and resource access. Use with Cabinet for access control and periodic review evidence. |
| TPRM (app_tprm) | Third parties, outsourcing | Manage vendors and external service providers (e.g. development, support). Use for contract and due diligence evidence where relevant to ISMS scope. |
| Configuration (app_conf) | Scope by entity | Define companies (e.g. bank, branch). Use to scope the ISMS by entity and align Framework Compliance instances. |
Quick mapping: Regulation area → SecBoard
| Regulation area | SecBoard modules to use |
|---|---|
| Governance, policy, strategy, BCP | Framework Compliance, Document Register, Legislative docs. |
| Risk management (п. 10–11) | Framework Compliance, Risk Assessment. |
| Access, roles, MFA (п. 36–41, 83–88) | Framework Compliance, Cabinet, Access, KeyCert (certs/tokens), Document Register, Study. |
| Crypto, keys (п. 44–56, 150) | Framework Compliance, Keys & Certificates, Document Register. |
| Logging & monitoring (п. 42–43, 127) | Framework Compliance, SOC, Document Register. |
| Incident management (п. 130–132) | Framework Compliance, Incident Register, Document Register. |
| Asset/inventory (п. 75, 113) | Framework Compliance, Asset management. |
| Awareness (п. 30–33) | Framework Compliance, Study, Gophish, Document Register. |
Getting started with the Regulation in SecBoard
- Create a framework: In Framework Compliance, create a Custom framework (e.g. “NBU 95 – Information security in the banking system”). Add control categories and controls aligned to Sections I–V (governance, risk, access, crypto, logging, anti-malware, network, incident, media, development, Section V additional measures).
- Governance and documents: Store policy, strategy, BCP, and internal documents (access, removable media, anti-malware, email, etc.) in Document Register. Link to controls. Assign CISO and security unit; document governing body and roles in Cabinet/Org Structure where relevant.
- Risk and assets: Use Risk Assessment for information security risk management (п. 10–11). Use Asset management for software list (п. 75) and device inventory (п. 113).
- Access and crypto: Use Cabinet and Access for users, roles, and minimal privileges; document periodic access review and MFA for admin. Use KeyCert for keys and certificates; Document Register for crypto policy and key management procedures.
- Logging and incidents: Use SOC for logging and monitoring evidence. Use Incident Register for incident process and storage (≥1 year). Link evidence to Framework Compliance.
- Review and NBU readiness: Use Framework Compliance dashboard to track status. Keep evidence current for NBU inspections and methodology (Methodological recommendations for inspection of ISMS).
NBU Regulation No. 95 and SecBoard
This guide is part of the documentation available in SecBoard. The Regulation on the organization of measures to ensure information security in the banking system of Ukraine (Положення, NBU Board Resolution 28.09.2017 No. 95) applies to banks; Section III also to non-bank participants of NBU information systems. Banks must implement an ISMS per DSTU ISO/IEC 27001:2015 and the Regulation’s mandatory measures (Sections IV and V). Use SecBoard Framework Compliance (Custom/Local framework) to map controls and evidence; use Risk Assessment, Incident Register, Asset, Keys & Certificates, Document Register, Cabinet, SOC, Study, Gophish, and Access to support governance, risk, access, crypto, logging, incident management, and awareness. Section V (additional measures) has been in force since 01.09.2019.
Align scope and evidence with the NBU methodology for inspection of the ISMS and keep documentation ready for NBU verification.
Frequently asked questions
What is the Regulation (No. 95)? — The NBU Board Resolution of 28 September 2017 No. 95 approved the Regulation on the organization of measures to ensure information security in the banking system of Ukraine. It requires banks to implement an ISMS (DSTU ISO/IEC 27001:2015), risk-based approach, Annex A controls (DSTU ISO/IEC 27002:2015), and mandatory measures in Sections IV and V (governance, CISO, access, crypto, logging, anti-malware, network, incident management, etc.). Section V took effect on 1 September 2019.
Who must comply? — Banks. Section III (cryptographic protection in NBU information systems) also applies to non-bank institutions that are participants in NBU information systems.
How do I map the Regulation in SecBoard? — In Framework Compliance, create a Custom or Local framework (e.g. “NBU 95”). Add control categories and controls per Sections I–V. Attach evidence from Document Register, Asset, KeyCert, Cabinet, SOC, Incident Register, Risk. Use the dashboard to track status.
Which modules support incident management (п. 130–132)? — Incident Register for recording, classification, response, and storage; Document Register for the incident process and procedures. Link evidence to Framework Compliance controls.
What about Section V (additional measures)? — Section V (п. 133–150) requires, among other things: removable media list and automated control; centralized account management; centralized security updates; automated incident management; PFS for TLS; OWASP for web apps; jump server; MFA for ISMS access; IDS/IPS; DoS/DDoS protection. Map these to controls in Framework Compliance and attach technical and procedural evidence.