Versions: OAC Order No. 130 as amended by Order No. 98 (in force since 1 July 2026); OAC Order No. 66 as amended, including by Orders No. 259, No. 98 and No. 102.
This guide is not a legal opinion. The requirements are summarized closely to the official Russian text; the exact wording is in the official publications listed under "Sources". The process recommendations are practice, not requirements of the acts. Whether a requirement applies to your organization is for your legal team and responsible officers to decide.
What is required
OAC Order No. 130, Annex 4, item 1, paragraph seven. Software of the information infrastructure object's assets and of the security tools used on it must be updated to current versions within a month of the update's release date.
There are two exceptions:
- the update is restricted by the vendor;
- the update would disrupt or stop the assets or security tools.
OAC Order No. 66, para. 7.8 of the list. For information systems processing restricted information, ensuring software updates and controlling their timeliness is mandatory for all typical information system classes.
How to do it is up to the organization. The organization chooses how to implement the Annex 4 requirements (Annex 4, item 2).
Three things that are easy to miss
- The clock starts at the update's release date, not when you learned about it or when a scanner found the old version. So you need to know when the update came out.
- Security tools are covered too: firewalls, intrusion detection, antivirus and so on. They are often updated less often than servers.
- An exception is never silent. If you do not update because the vendor restricts it or the update breaks the system, the auditor will ask why. Prepare and record the answer in advance.
How to build the process
The practice below helps you stay within a month and show it to an auditor. These steps are not requirements of the acts.
| Step | What to do | Evidence it leaves |
|---|---|---|
| 1. Inventory | List assets and security tools with software versions and owners | Asset register |
| 2. Update sources | For each product, where updates are published (website, mailing list, repository) | List of sources |
| 3. Track releases | Record the release date of every update; the month counts from it | Update log: product, version, release date |
| 4. Prioritize | First, vulnerabilities that are actually exploited (for example, from the KEV catalog) and internet-facing systems | Priority decision |
| 5. Test and install | Test in a staging environment, install in a maintenance window | Install date in the log |
| 6. Exceptions | If you cannot update: the reason (vendor restriction or disruption), compensating measures, review date | Exception record signed by the owner |
| 7. Control | Regularly compare actual versions against the log: did everything make the month? | Review report (Order No. 66, para. 7.8 requires control of timeliness) |
Tip. The easiest answer for an auditor is one table: product, version, update release date, install date, days between, exception (if any).
Where a scanner helps
A scanner sees outdated software versions with known vulnerabilities on reachable services. It is a good way to find what fell out of the inventory and to confirm that an update was actually installed.
But a scanner has limits:
- it often reads the version from a banner, and distribution vendors ship fixes without changing the version number, so false positives happen;
- it does not know the release or install date, so on its own it cannot tell whether the month has passed;
- software without network services (workstations, internal components) is not visible from outside.
More on what a scanner sees and what only documents prove: SGRC or vulnerability scanner.
ISO/IEC 27001
The closest control is A.8.8 Management of technical vulnerabilities. The standard sets no fixed deadline, so "within a month of release" has to be written into your own policies. See ISO/IEC 27001 and the Belarus requirements.
Critical vulnerabilities and cybersecurity centers
Cybersecurity centers have a separate deadline: they report critical vulnerabilities to the National Cybersecurity Center within one hour (Order No. 130, item 6 of the Regulation on information exchange). All reporting deadlines are in the Decree No. 40 guide.
How Cyber-Cortex helps
Cyber-Cortex maps outdated software versions to the within-a-month update requirement (Order No. 130, item 1, paragraph seven; Order No. 66, para. 7.8) and to ISO/IEC 27001, NIST CSF 2.0 and CIS Controls, with an explanation of why and a remediation recommendation. Findings indicate potential non-compliance; the conclusion is for your organization's responsible officer.
The full Annex 4 checklist is in the Order No. 130 guide. Terms are explained in the glossary.