- Security
- A
Connecting to SMEV: Theory, Practice and Pitfalls
If you work in a bank, insurance, microfinance organization, or any other entity that needs to verify client passports, request information from the Unified State Register of Legal Entities, or obtain information about criminal records, sooner or later you will encounter SMEV. And you will likely find that connecting to it is more complicated than it seems.
In this article, we will explain how the connection process works, at what stages it usually stalls, and we will analyze a practical example of how we at Cloud4Y helped a client navigate this path.
What is SMEV and why is it important for business
SMEV (System of Interdepartmental Electronic Interaction) is an infrastructure through which government and municipal bodies exchange data. Initially, the system was created so that officials would not have to send citizens for certificates: instead of "bring a statement from the Pension Fund," the agency itself requests data through SMEV.
Over time, commercial organizations began to connect to the system as well — provided they have legal grounds and follow the established procedure.
Typical use cases include:
verification of client passport data (validity of the passport);
obtaining information from EGRUL/EGRIP;
checking TIN, SNILS;
obtaining information about the presence (absence) of a criminal record;
obtaining information from the Unified State Information System for Healthcare (EGISZ) for medical organizations connected under the requirements of the Ministry of Health.
For businesses, this is a way to automate checks and reduce risks: instead of taking the client’s word for it, you get data directly from government information systems.
The first barrier: can you even connect?
Here is where it gets interesting. SMEV is not a public API that anyone can connect to. There is a specific circle of organizations for which access is granted through a simplified procedure. If you are a government agency, a local self-government body, or an organization directly involved in providing government services — it is easier for you.
All others are considered "other organizations." And for them, the path lies through the subcommittee on the use of information and communication technologies of the Government Commission for Digital Development.
This is exactly where we started when a client approached us with a request for connection. The first thing we did was check whether the organization belongs to the category with simplified access. It turned out that it does not. This immediately changed the work plan: instead of "set up the connector and go" — there would be a commission, documents, and approvals first.
Important: check your status before you start technical preparation. A mistake at this stage can cost weeks of wasted work.
What documents are needed for the commission
For "other organizations," a package of documents is requested to confirm that you know how to handle personal data and understand what information security is. Formally, the set looks standard, but in practice, its contents are treated with quite a bit of attention.
Mandatory package:
Document | What it is |
Application for connection | Formal request in the established form |
Threat model for personal data security | Description of current threats to your ISPDn |
Regulations on personal data security | Data protection procedures in the organization |
Regulations on personal data processing | Policy for working with personal data |
Sounds like a formality? Not at all.
Documents: where difficulties arise in practice
At this stage, many organizations face difficulties — not because they have no documents on information security at all, but because they do not always correspond to the real data processing scheme and the future connection to the SMEV.
Most often, problems look like this:
The threat model describes the personal data information system (ISPDn) in general terms, without reference to specific infrastructure, communication channels, and used protection measures. As a result, it is impossible to understand from the documents which specific risks are taken into account when accessing state information systems.
Regulations for ensuring the security of personal data formally exist, but do not reflect real processes: who requests the information and on what basis, how access control is carried out, and how cryptographic protection means (SKZI) are used when interacting with the State Information System (SMEV).
The categories of processed data and the purposes of processing are stated too generally, without differentiation by types of requested information and usage scenarios.
For the commission, this is fundamentally important: when reviewing an application, the declared types of information, the connection scheme, and the documents on information security (IB) are compared. If there is no logical connection between them, the documents are usually returned for revision.
In our case, the situation was exactly like that. The formally required set of documents was available to the client, but it did not take into account the specifics of connecting to SMEV and the actual architecture of the system. We conducted an assessment of the compliance of processes with the requirements of legislation in the field of personal data protection and information security, revised the documents taking into account the real processing and interaction scheme with SMEV, and prepared a package for submission to the commission.
The result — a positive decision without repeated iterations and additional requests.
Commission: what to expect
The commission meets periodically (not every day), so time should be allocated for waiting. In our experience, from the submission of documents to the decision can take from a few weeks to one and a half months — it depends on the meeting schedule and workload.
What could go wrong:
documents are not formatted correctly — return for revision;
the threat model does not correspond to the type of processed data;
the IB regulation contains obvious contradictions;
specific types of information that are planned to be requested are not indicated.
Each iteration means weeks of waiting. Therefore, it is critically important to prepare the package correctly the first time.
Technical connection: secure channel
After the commission's approval, we can move on to the technical part. Here, the main focus is on organizing a secure communication channel.
To simplify, SKZI is a certified cryptographic gateway through which your network connects to the SMEV infrastructure. The connection is made not through the open internet, but through a secure data transmission network using certified means of cryptographic protection of information.
SMEV is not the open internet. The connection is made through a secure data transmission network using certified SKZI.
The main options for SKZI:
ViPNet (InfoTeCS);
Kontinent (Security Code);
S-Terra.
The choice depends on what is already used in your infrastructure, regulatory requirements, and budget.
After approval, our client decided on the connector, and we took care of organizing the channel. In accordance with the regulations, we chose ViPNet Coordinator. Next — submitting requests to Rostelecom (which administers the SMEV infrastructure), agreeing on connection parameters, providing equipment, and interacting with Rostelecom specialists during the configuration stage.
We carried out all this work ourselves, without involving the client in technical routine. Upon completion, they received a functioning secure channel. The client independently configured the connector for data exchange with SMEV.
Checklist: What is Needed to Connect to SMEV
For those who plan to go through this process — a brief checklist.
Stage 0: Status Determination
Check if the organization belongs to the category with simplified access
Determine what types of information need to be received
Stage 1: Documents
Current regulation on personal data processing
Threat model corresponding to the actual infrastructure
Regulation on ensuring the security of personal data
Application in the established form
Stage 2: Commission
Submit documents
Wait for the meeting and decision
If necessary — revise and resubmit
Stage 3: Technical Connection
Select a connector for working with SMEV
Select a cryptographic protection tool (ViPNet / Kontinent / S-Terra)
Submit an application to the infrastructure operator
Agree on the connection scheme
Install and configure the equipment
Configure the connector
Estimated timelines (if everything goes well):
Document preparation: 2–4 weeks
Waiting for the commission's decision: 3–6 weeks
Technical connection: 2–4 weeks
Total: 2–3 months from start to operational connection.
Conclusions
Connecting to SMEV is not just a technical integration. A significant part of the work lies in the realm of organizational security and bureaucracy.
Three key points:
Start by checking your status. If you are not in the category with simplified access, allow time for the commission.
Documents must reflect reality. "For show" will not pass — the commission looks at adequacy.
Technical connection is the finale, not the start. Do not purchase equipment before the commission's approval.
We at Cloud4Y regularly help companies connect to SMEV, EGISZ, and other secure state networks. If you don't want to deal with the nuances yourself, we provide ViPNet as a service: renting a crypto gateway, configuration, and support for the connection.
Write comment