NBU Resolution No. 143 requires insurers, credit unions, finance companies and pawnshops to introduce a process for managing cyber and information security incidents and to draw up and approve a response plan. Operations must be brought into line by mid-December 2026. For an overview of the resolution, see “NBU Resolution 143: cybersecurity rules for NBFIs”.
This article looks at the response plan in detail: what it must contain according to the resolution, and how to make it a working tool rather than a document in a drawer.
This article is an overview based on the official text of the resolution, not legal advice. Agree how the requirements apply to your institution with your lawyer.
What the resolution requires
Section III of the Regulation approved by Resolution No. 143 sets out:
- A process and a plan. The institution introduces a process for managing cyber and information security incidents and draws up and approves a response plan.
- A link to continuity. Responding to cyber incidents is part of contingency planning and is considered together with other security incidents. The plan is drafted with reference to business continuity documents or forms part of the business continuity plan.
- Mandatory contents of the plan: assessment of the negative impact (damage); the responsible person’s procedure; the actions of users and privileged users; how the responsible person works with staff of core business processes; how the head is informed; how information about incidents, their analysis and the response results is kept.
- Contractors. For fast response and continuity, the institution works with the parties it engages — software developers, system integrators, technical support companies. Contracts with them must include terms for cooperation during incidents, and while the contract is in force the institution monitors events that affect or may affect its services.
- NBU requests. The National Bank may request information on incident response in writing; the head ensures that reliable information is provided within the deadline, scope and format set in the request.
The Regulation defines an information security incident as an event or series of events that may cause losses to the institution or threaten the confidentiality, integrity and availability of its information. Monitoring and investigating incidents is the duty of the responsible information security person.
Plan structure: a working template
| Plan section | What it covers | Basis in the Regulation |
|---|---|---|
| Terms and severity levels | what counts as an incident, how severity is set | definitions |
| Impact assessment | damage criteria: financial loss, impact on clients, disclosure of financial service or insurance secrets, downtime of core business processes | assessment of negative impact |
| Responsible person’s actions | detection, assessment, containment, eradication, recovery, analysis | responsible person’s procedure |
| User actions | how and to whom to report a suspicion, what not to do | actions of users |
| Working with the business | who decides to stop a service, how clients are informed | cooperation with core business processes |
| Informing the head | when and in what form, who deputises | informing the head |
| Register and analysis | what is recorded, where evidence is kept, how conclusions are captured | keeping and analysing information |
| Contractors | contacts, roles, contractual response times | cooperation with engaged parties |
| NBU requests | who prepares the answer and from what data | NBU right to request information |
| Continuity | how the plan links to the business continuity plan | link to continuity |
Response stages
NIST’s updated incident response recommendations (SP 800-61 Rev. 3, 2025) build incident response into the NIST CSF 2.0 risk management framework: preparation relies on the Govern, Identify and Protect functions, and the response itself on Detect, Respond and Recover. In practice the plan should cover these steps:
- Preparation. Up-to-date contacts, access for the response team, configured event logs (the Regulation separately requires them to be recorded, protected and kept for at least a year — the basis of any investigation), tested backups, trained users.
- Detection and assessment. Where signals come from: security monitoring, users, contractors. Initial classification and impact assessment against the plan’s criteria.
- Containment. Isolating affected systems, blocking accounts, changing passwords. The decision to stop a client-facing service is taken together with the business process owner.
- Eradication and recovery. Restoring from verified backups — only after the way in has been closed. On building backup: “3-2-1 backup rule: protecting business data”.
- Post-incident analysis. An entry in the register, conclusions, updates to the plan and to protective measures.
Contractors: what to put in the contract
- Non-disclosure. The Regulation explicitly requires non-disclosure terms in contracts with parties engaged for security measures and incident response.
- Restrictions. Such a contractor may not be a resident of the aggressor state or have such ultimate beneficial owners, nor process or store data in clouds or data centres located in the aggressor state or the temporarily occupied territories, or owned by sanctioned persons.
- Cooperation during incidents. Contacts, agreed response times, who does what, access to logs, participation in investigations.
- Incidents on the contractor’s side. A duty to report events that affect or may affect your services — the resolution requires such events to be monitored throughout the contract.
How to be ready for an NBU request
Answering a written request from the National Bank is easier if the data is already collected. Keep an incident register: date and time of detection, description, impact assessment, decisions taken, actions, contractors involved, outcome and conclusions. Store event logs and contractor reports so they can be found and handed over quickly.
How to check that the plan works
A plan nobody has rehearsed rarely works in a real incident the way it is written. Run tabletop exercises — talking a scenario through with all participants:
- ransomware on a file server;
- an email “from the CEO” or “from a counterparty” asking for an urgent payment;
- a leak of client data;
- a denial-of-service attack on a client-facing service;
- an incident at a contractor with access to your systems.
After every exercise, update the plan and walk staff through it — the Regulation requires users to acknowledge internal security documents by signature or in another verifiable way.
Checklist
- The incident management process is in place, the response plan is approved
- The plan is linked to the business continuity plan
- Severity levels and impact criteria are defined
- The responsible person’s actions are described for every stage
- Users know how and to whom to report and have acknowledged the plan by signature
- Cooperation with business process owners and the way the head is informed are defined
- An incident register is kept, event logs are retained for at least a year
- Contractor agreements include non-disclosure and incident cooperation terms
- It is clear who prepares the answer to an NBU request
- Tabletop exercises are run regularly and the plan is updated after them
How Bereg-IT can help
At a consultation or an audit we assess your current response process and help prepare a plan in line with the resolution. SOC as a Service takes on collecting and analysing security events, triage and investigation, notifications with a severity assessment, response according to an agreed playbook and regular reports — and the split of responsibilities between us and your team is fixed before launch. If an incident is happening right now, see the first steps on the “Security incident” page.
The first consultation is free. Send a request and an information security specialist will get in touch.
Sources
- Resolution of the Board of the National Bank of Ukraine of 09.12.2025 No. 143 “On approval of the Regulation on organising information security and cyber protection measures by financial service providers”, Section III (in Ukrainian): https://bank.gov.ua/admin_uploads/law/09122025_143.pdf
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025): https://csrc.nist.gov/pubs/sp/800/61/r3/final
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29 (2024): https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf