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". Whether a requirement applies to your organization is for your legal team and responsible officers to decide.
In short
- A vulnerability scanner answers "what is technically wrong in the infrastructure": open ports and services, outdated software, weak settings, known vulnerabilities.
- An SGRC system (Security Governance, Risk and Compliance) answers "how do we manage security": asset and risk registers, requirements, compliance assessments, tasks and owners.
- The OAC requirements cover both sides. Some can be checked technically, others only through documents and processes. So neither class of tools covers the whole picture on its own.
What a vulnerability scanner gives you
A scanner connects to network hosts and looks at what is reachable and in what state.
Strengths.
- Objective technical data: not a questionnaire, but what is actually visible on the network.
- Freshness: a repeat scan shows what changed.
- Vulnerability identifiers (CVE) and severity scores (CVSS).
Limits.
- A scanner report speaks the language of technology: "port 3389 is open", "version is outdated". It does not say which paragraph of which act is affected.
- Priorities follow CVSS, not which requirement is breached and how much it matters to the organization.
- A scanner cannot see processes: how long logs are kept, whether there is an incident reporting procedure, who is responsible.
What an SGRC system gives you
An SGRC system keeps the records and runs the compliance process.
Strengths.
- A register of requirements and a compliance assessment for each.
- A risk register, decisions, owners and deadlines.
- Audit evidence and reports for management.
Limits.
- Technical data enters the system from questionnaires, documents or integrations. Without integrations, "compliant" reflects what people declared, not what the network shows.
- Between a vulnerability in a scanner report and a requirement in the register sits manual work: someone has to decide which requirement is affected.
OAC Order No. 130: what checks what
Annex 4 to OAC Order No. 130 (as amended by Order No. 98) has requirements that are visible from the outside and requirements that can only be checked through documents and settings. The full checklist is in the Order No. 130 guide.
| Requirement (Annex 4, item 1) | Visible to a scanner | Needs documents and processes |
|---|---|---|
| Default credentials changed or blocked (paragraph three) | Factory credentials on reachable services | How passwords are changed and stored |
| Identification and authentication, lockout after failed logins (paragraph four) | Services without authentication | Lockout settings, removal of unused accounts |
| Restricted administrative access (paragraphs five and six) | RDP, SSH, management interfaces reachable from the internet | Logging of access attempts, review of admin rights |
| Software updates within a month (paragraph seven) | Outdated software versions with known vulnerabilities | Update release and install dates, exceptions |
| Firewalling and intrusion detection (paragraph nine) | Services and databases reachable from the internet without need | Intrusion detection and prevention tools in place and working |
| Event collection, kept for at least a year (paragraph ten) | — | Log sources, actual retention period |
Incident reporting deadlines (one hour for cybersecurity centers under Decree No. 40, para. 3.8; 24 hours for information system owners under Order No. 66) are a process; a scanner does not check them.
How to choose
Ask three questions:
- Do you need the real technical state, not the declared one? Then you need a technical assessment.
- Do you need to show compliance paragraph by paragraph to an auditor or management? Then you need a requirements register and a link from findings to paragraphs.
- Who will translate the scanner report into requirements by hand? If nobody, you need an automatic "finding → requirement" link.
How Cyber-Cortex does it
Cyber-Cortex brings both sides together:
- infrastructure assessment: discovery of assets, services, ports, OS, certificates and exposed surfaces; built-in nmap and nuclei plus native HTTP, TLS and DNS checks;
- mapping: every finding is automatically linked to the paragraphs of Decree No. 40, OAC Orders No. 130 and No. 66 and Law No. 99-Z, and to ISO/IEC 27001, NIST CSF 2.0 and CIS Controls, with an explanation of why;
- remediation plan: prioritized recommendations that close gaps across all frameworks at once;
- CISO dashboard: compliance by framework, risk trend and top issues for management.
Example: RDP reachable from the internet maps to Order No. 130, Annex 4, item 1, paragraphs five and six (restricted administrative access) and para. 7.9 of the Order No. 66 list (isolated management network for classes 3-*), plus a remediation recommendation. Findings indicate potential non-compliance; the conclusion is for your organization's responsible officer.
Only scan infrastructure you own or have the owner's permission to test. Terms are explained in the glossary.