What ONiVD and the ONiVD plan are: the abbreviations explained
ONiVD means ensuring operational continuity and/or recovery. It is the Bank of Russia term for what international practice calls business continuity management. PONiVD, the ONiVD plan, is the plan for ensuring operational continuity and/or recovery, the main document of this system.
The abbreviations look clumsy, but the idea behind them is simple. The regulator wants the bank to know the answers to three questions in advance. Which processes must not stop. How long the organisation can survive without them. What exactly people do, and in what order, when a process does stop.
The ONiVD plan differs from an “ordinary” continuity plan in status. Their content is similar. For supervised organisations it is a mandatory supervisory requirement with parameters that can be checked. The regulator looks at whether the document exists, and also at the dates it was updated, test results, recorded incidents and actual recovery times.
ONiVD plan template and test report
Two working documents for this page. The plan template follows the eleven sections of the structure below, from scope to the update procedure, with recovery procedure modules. The test report records the test programme, timings, results and the gaps found, with a plan to fix them.
Download. ONiVD plan template and plan test report. Format: docx.
Notes on each section: ONiVD plan template (in Russian) and testing the plan and a module (in Russian). No registration, no forms. If you need to build the whole ONiVD system: Turnkey BCM.
Regulatory framework for 2026
This is where the most common mistake happens. Most articles and many current internal bank documents still refer to Regulation 787-P. Bank of Russia Regulation No. 787-P of 12 January 2022 was repealed on 3 May 2025. It was replaced by Regulation No. 850-P. If an organisation's internal document refers to 787-P, the document needs to be revised.
| Document | What it covers | Who it applies to |
|---|---|---|
| Regulation No. 850-P of 13 January 2025 | Operational reliability requirements to ensure the continuity of banking services. In force since 3 May 2025, some provisions since 1 October 2025. Replaced 787-P | Credit institutions, including non-bank credit institutions, and branches of foreign banks in Russia |
| Regulation No. 779-P of 15 November 2021 | Operational reliability requirements for non-credit financial institutions | Non-credit financial institutions, insurers, professional securities market participants |
| Regulation No. 716-P of 8 April 2020 | Operational risk management system, operational risk event database, operational risk control indicators. It also contains the requirement for the ONiVD plan | Credit institutions and banking groups |
| Regulation No. 851-P | Information protection in banking activities. Replaced 683-P. 850-P refers to it on critical architecture | Credit institutions |
| GOST R 57580.3 and 57580.4 | Specific measures that implement the requirements for operational reliability and information security risk management | Used as a way to meet the requirements of the regulations |
| Directive No. 3439-U | Procedure for recognising an organisation as significant in the payment services market. Stricter requirements depend on this status | Money transfer operators |
The regulatory framework is listed as of 21 August 2026. Before drafting internal documents, check the current version on the Bank of Russia website. Regulation in this area changes roughly every two to three years.
Who must comply
The requirements apply, to different extents, to credit institutions, branches of foreign banks in Russia, non-credit financial institutions, insurance companies, professional securities market participants, payment system operators and significant payment service providers.
The scope of the requirements depends on two things. The first is the size of the organisation. For banks with assets over RUB 500 billion, the threshold values are stricter. The second is recognition as significant in the payment services market. Such an organisation has six months from the date of recognition to set signal and control values. Its requirements for payment technological processes become the same as those for the largest banks.
Contractors deserve a separate note. If your company serves a supervised organisation, for example provides an IT service, processes data or provides communications, continuity requirements will reach you through the contract. The bank must manage its dependence on suppliers. So it will ask you for a recovery time objective, an incident notification procedure and participation in tests.
How the plan is built
The ONiVD plan starts from processes. The sections come later. The sequence is as follows.
Step 1. Identify technological processes
The regulator works with technological processes. Departments and systems are not its unit of analysis. Technological processes are end-to-end chains that deliver a service to the client: accepting and processing a payment, cash withdrawal, remote banking, lending, account servicing. The list of processes and their threshold values are set in the annexes to 850-P. The organisation does not make up this list itself.
Step 2. Set the tolerable downtime
Each technological process has a threshold for tolerable downtime. This is the upper limit. Beyond it, a breach begins. Within this limit the organisation sets its own targets, usually stricter ones. If the target sits right at the regulatory limit, the very first disruption becomes a breach.
Step 3. Set the tolerable degradation share
This is the second indicator, and it matters more than it seems. The degradation share is the ratio of the number of operations performed or not performed during an incident to the planned number of operations in normal mode. In other words, a process may formally work but serve thirty per cent of clients instead of a hundred. For this indicator, signal and control values are set in line with the operational risk control indicators.
Step 4. Set the incident recording threshold
An operational reliability incident is recorded when the degradation share stays above its signal value for more than five minutes. Short spikes do not count as incidents. This detail matters for setting up monitoring. If the alert system fires on every deviation, the team drowns in false alarms. If it reacts more slowly than five minutes, the organisation misses an incident it must record.
Step 5. Link to the operational risk event database
All incidents that caused losses are registered in the operational risk event database under 716-P. The record includes the actual downtime, the degradation share during the incident, the total downtime and the results of restoring operations. The data for reporting and for reviewing targets also come from here.
Step 6. Describe scenarios and actions
Only at this step does the actual text of the plan appear. Scenarios are written for processes and threshold values that are already known. The reverse order does not work. This is why plans that start from a template of sections almost always fail in practice. They contain neat procedures but do not say how many minutes you have and how to tell that you have run out of time.
ONiVD plan structure: eleven sections
A working structure that meets the requirements and can be used in a real crisis as well as for an inspection.
- Scope and list of technological processes. Which processes the plan covers, their owners, the threshold tolerable downtime and the targets for each.
- Operational reliability targets. Tolerable downtime, signal and control values of the degradation share, and how they are reviewed.
- Critical architecture. Information infrastructure objects that support the processes, the dependencies between them, single points of failure.
- Disruption scenarios. Information system failure, loss of access to premises, loss of key staff, supplier failure, cyberattack, communication channel failure, power failure.
- Plan activation procedure. Who declares disruption mode, on what triggers and within what time; who stands in for this person in their absence; how the moment of activation is recorded.
- Recovery procedures. Step-by-step actions for each scenario, with the people responsible, the deadlines and the point at which the decision to switch to the backup arrangement is made.
- Communications. Alerting staff, informing clients, notifying the Bank of Russia, dealing with the media, message templates.
- Backup resources. Backup sites, communication channels, backups, the switchover procedure and time, who has the right to start the switchover.
- Dependence on suppliers and key staff. List of critical external dependencies, the requirements for them in contracts, how to work if an employee with unique skills is lost, including periods of remote work.
- Testing procedure. Types of tests, frequency, the test programme, success criteria, how results are documented.
- Update procedure. Regular review and the events that trigger an unscheduled review of the plan.
Sample wording: good and bad
The difference between a plan that passes an inspection and one that fails is usually visible in individual phrases. The inspector looks for things that can be verified: a deadline, a responsible person, a sign that the event has occurred. Below are pairs of wordings from real practice, anonymised.
| Avoid this | Do this |
|---|---|
| “In the event of an emergency, the unit takes the necessary measures to restore operations as soon as possible.” | “If the payment acceptance process is unavailable for more than 5 minutes, the on-duty administrator moves the load to the backup environment within 10 minutes and notifies the head of the operational risk function. Recovery time objective: 30 minutes.” |
| “The IT department is responsible for operational continuity.” | “The deputy chair of the management board in charge of operations is responsible for ONiVD. The owner of technological process TP-4 is the head of the settlements department, who decides on activating the plan for this process.” |
| “The plan is subject to regular review.” | “The plan is reviewed at least once a year by 1 March, and also within 20 working days after each of these events: a change in the list of technological processes, a change in the critical architecture, an incident that exceeds the control value, a change in regulatory requirements.” |
| “Backups are made on a regular basis.” | “A full backup of the core banking system database runs daily at 02:00. Copies are kept for 30 days. Every quarter a test restore from a copy is carried out and recorded in a report.” |
| “Staff are alerted by available means of communication.” | “Alerts follow a call tree. The first round is the 12 members of the crisis team. Confirmations must be collected within 20 minutes. Contact details are kept in two places, including a printed copy in the duty shift safe.” |
| “The plan is tested periodically.” | “Every year there is at least one live switchover to the backup site and at least two tabletop scenario walkthroughs. Results are recorded in a report listing the gaps found and the deadlines to fix them.” |
| “Interaction with suppliers is carried out under the contracts concluded.” | “For critical suppliers, the contract sets a response time of 30 minutes, a recovery time of 4 hours and an obligation to take part in annual testing. The list of such suppliers is in Annex 3 and is reviewed every year.” |
| “Information on incidents is reported to management.” | “An operational reliability incident is registered in the operational risk event database within one working day. If the degradation share exceeds the control value, the chair of the management board is informed immediately, and the board of directors as part of quarterly reporting.” |
The general rule is simple. If a phrase does not tell you exactly who acts, by when and on what trigger, the phrase does not work, even if it is well written.
Responsibility within the bank
The second most common question after what the term means: who is responsible for ONiVD and who activates the plan. The document must answer this with named individuals. Naming departments is not enough.
| Role | What it covers |
|---|---|
| Board of directors | Approves the approach to operational risk management and the acceptable level of risk, reviews reports on continuity disruptions, assesses whether the measures taken are sufficient |
| Management board | Approves the ONiVD plan and targets, provides resources, answers to the board of directors and the regulator for the actual state of the system |
| ONiVD executive owner, deputy chair of the management board level | Single point of accountability for the system as a whole. This person is named in documents as the responsible person. A deputy is appointed by order |
| Risk management function | Methodology, continuity risk register, operational risk event database, calculation of indicators, reporting, coordination of tests |
| Technological process owner | Knows the tolerable downtime of their process, decides on activating the plan for that process, keeps recovery procedures up to date |
| IT | Redundancy, recovery of systems and data, switchover to the backup environment, the technical part of tests |
| Information security | Cyberattack scenarios, alignment with 851-P and GOST R 57580, response to information security incidents |
| Internal audit function | Independent check that the system really works and does not just exist on paper. Looks at the actual tests and does not rely on the reports alone |
| Crisis team | Operational management during a disruption. Members, deputies and the assembly procedure are set out in the plan |
A practical check of who is responsible takes five minutes. Open the plan and find who declares disruption mode at 3 a.m. on a weekend if the main responsible person cannot be reached. If there is no answer, the roles exist only on paper.
How often to update and test
The regulations set frequency through a set of requirements for different elements of the system. There is no single figure. We bring them together into a calendar that is easy to live by.
| What | How often | Basis and purpose |
|---|---|---|
| Calculation of the operating time of technological processes, including planned downtime | Quarterly | Data to monitor compliance with threshold values and to justify targets |
| Review of operational reliability target values | At least once a year | Takes the operational risk control indicators into account. The basis for review is the accumulated incident statistics |
| Assessment and review within the operational risk management system | At least once a year | 716-P, keeping the system up to date |
| Operational reliability testing | According to the set programme and the frequency fixed in internal documents | Scenario analysis plus a qualitative assessment of the operational risk level. The organisation sets the frequency itself, but it must be defined and followed |
| Review of the ONiVD plan | At least once a year, plus unscheduled reviews | Unscheduled: when the list of processes, the critical architecture, the organisational structure or the set of critical suppliers changes, after a significant incident and when requirements change |
| Updating contact details and alert schemes | Quarterly | Not a separate formal requirement, but this is the part of the plan that goes out of date fastest |
| Setting signal and control values when an organisation is recognised as significant in the payment services market | No later than 6 months from the date of recognition | Directive 3439-U read together with 850-P |
A separate note on types of tests. A tabletop walkthrough of a scenario by the crisis team shows whether people are ready. It says nothing about whether the technology is ready. A live switchover to the backup site answers the technical question, but it is rarely done because of the risk to production. A workable combination for a mid-sized bank is several tabletop walkthroughs and one live switchover a year, always with a report and a plan to fix the gaps found. The annual test programme, a tabletop scenario and a report template are covered in the article testing the ONiVD plan (in Russian).
Good and bad practice in plan development
What works
Start with processes. The table of contents comes later. First the list of technological processes, their owners and threshold values. The text of the plan is written last and takes less time than it seems.
Have process owners write the plan. A consultant provides the structure and the requirements and facilitates the work. The recovery procedure is written by the person who will carry it out. At the very first incident, a plan written entirely by an outside contractor turns out to be unclear to the people who have to use it.
Keep the plan short. Nobody will open two hundred pages during an emergency. A workable format is a compact main document plus annexes with one-page action cards for each scenario. They can be printed and kept with the duty shift.
Count the money. The cost of one hour of downtime for each critical process turns a debate about the redundancy budget into a calculation. Without this figure, any request for a backup site looks like a department's whim.
Test the plan against real incidents. After each disruption, even a minor one, it is useful to check whether the actual actions matched the written ones. This teaches more than a scheduled exercise.
What does not work
A template without implementation. A bought or downloaded template speeds up the start. But an inspection assesses the system, and a document alone does not pass. Signs of implementation are recent dates, named roles, test reports and recorded incidents.
The plan as an IT department project. If only IT develops the plan, it will cover systems and leave out processes, clients and communications. The regulator looks at whether services continue. Server availability alone does not answer that.
Targets set right at the regulatory limit. If an organisation sets itself exactly the threshold time, any deviation immediately becomes a breach. An internal target needs a margin.
Testing without conclusions. If an exercise does not end with a list of gaps and deadlines, it was only for show.
References to repealed documents. Checking internal documents for current regulatory references takes an hour. A reference to 787-P found in the plan makes the whole document worthless in the inspector's eyes.
Where organisations stumble in inspections
A plan exists, a system does not. The document was written three years ago, the phone numbers are out of date, and some of the named staff have left. Formally the requirement is met. In practice the plan is useless in an incident, and an inspection sees this from the update dates and the lack of test reports.
Tests on paper. Exercise reports are written without the exercises taking place. The risk is double, both supervisory and real: the first real disruption becomes the first test.
Indicators are not calculated. Target values are written in the document, but actual values are not measured, because monitoring is not set up for the five-minute threshold and the degradation share. As a result, incidents are not recorded, the event database is empty and reporting is a formality.
No link to money. The plan does not say what one hour of downtime costs for each critical process. So there is no sound basis for choosing what to restore first.
Supplier dependence is not described. The organisation knows its own systems but does not know what will happen if external processing or the only telecom operator's channel is unavailable.
Frequently asked questions
ONiVD means ensuring operational continuity and/or recovery. PONiVD, the ONiVD plan, is the plan for ensuring operational continuity and/or recovery. A bank must have this document under Bank of Russia requirements. The first is a system, the second is its main document.
A document that describes how the bank will keep critical operations running and restore them after a disruption: the list of critical processes, recovery times, responsible persons, the activation procedure, backup sites and systems, and the notification procedure. The eleven-section structure is covered above.
A part of the plan that describes actions for one type of event or for one process: a module for a data centre failure, a module for loss of office access, a module for a cyberattack. A modular structure lets you activate only the part of the plan you need and update modules independently.
A decision by an authorised person to switch from normal operations to the mode described in the plan module. The activation is recorded in writing, with the time, the grounds and who made the decision. From that moment the roles and deadlines in the plan apply instead of the usual procedures.
At the notification stage: the duty service and the manager who decides on activation. At the recovery stage: the response team, the owners of critical processes and IT. At the return to normal operations: the same process owners and the unit responsible for the plan, which records the results and lessons learned.
The bank sets the frequency itself in its internal documents. In practice, the whole plan is tested at least once a year and individual modules more often. Test results are documented and reviewed by management. This is a direct checkpoint during an inspection.
Continuity requirements for non-credit financial institutions are set by separate Bank of Russia acts for each type of activity: for insurers, professional market participants, non-state pension funds and infrastructure organisations. The direct requirement of 850-P is addressed to banks, but the approach to the plan is the same, and the supervisor expects significant non-credit financial institutions to have one.
An operational reliability incident is recorded when the degradation share stays above its signal value for more than five minutes. The plan activation threshold is written into the plan itself. Without it, every activation decision turns into an argument.
No. The disaster recovery plan (DRP) covers IT systems and data and is one of the modules of the ONiVD plan. The ONiVD plan is wider. It covers how business operations continue, people, premises and counterparties. The difference is explained in the article BCP and DRP.
The ONiVD executive owner, at deputy chair of the management board level, is responsible for the system as a whole. The management board approves the plan. The board of directors approves the approach and the acceptable level of risk. The risk management function runs the methodology, reporting and coordination of tests. Technological process owners, IT and information security write and carry out the recovery procedures. Internal audit checks that the system works. A detailed table of roles is in the section “Responsibility within the bank”.
How does the ONiVD plan differ from a BCP? In content, hardly at all. It is a continuity plan in Bank of Russia terms. The differences are the mandatory set of sections, the link to technological processes with set threshold values, and supervisory reporting. An existing BCP is usually extended to meet the requirements. It is rarely rewritten from scratch. More on the differences between plans in the review BCM, BCP and DRP.
Is 787-P still in force? No. Regulation 787-P was repealed on 3 May 2025. Regulation 850-P of 13 January 2025 is now in force. For non-credit financial institutions, 779-P remains in force.
Who activates the ONiVD plan? The person named in an internal document. This is usually the technological process owner or the duty shift manager, once the set triggers are reached, with immediate notice to the ONiVD executive owner. The key requirement is that the activation procedure and the arrangements for deputies are written down and work outside working hours.
How long does development take? For a mid-sized organisation, six to ten weeks to a working first version: description of technological processes, targets, the plan, the first test. Bringing an existing plan in line with current regulations usually takes three to four weeks.
Which situations fall within the scope of ONiVD? Failure of information systems and communication channels, loss of access to an office or site, loss of a significant part of the staff, failure of a key supplier or counterparty, a cyberattack, and events that affect the continuity of payments. The list is set out in the plan and reviewed every year.
From the requirements of the standard to a working system
The assessment shows the gap between your documents and reality. Then the system is built either by your own team in the programme or by us as a turnkey project.