Solutions
We align ISPDn with GDPR using a threat model, PP-1119 protection levels, FSTEC Order No. 21 measures, and an operational framework.
Our clients
Ten years ago, GDPR compliance looked like a set of documents: processing policy, orders, list of storage locations, and an instruction log. Inspection came down to whether those papers existed and were signed. That model lasted as long as the cost of a mistake was comparable to compliance spending.
The cost is different now. A repeat breach turns the fine into a turnover-based penalty, a percentage of annual revenue with a floor of RUB 20 million. The operator must notify Roskomnadzor of the incident within 24 hours and report the investigation results within 72 hours. Meeting that deadline is only possible if you already know what data was stored where and who accessed it. A policy folder does not answer that question.
The practical gap is almost always the same: the company does not know its own personal data map. Personal data exists not only in the system everyone calls the personal data information system. It moves through integration exchanges, lands in analytics exports, gets copied into test environments, ends up in application logs and backups. Protection measures are selected for one system on the list, while the breach happens where the map never reached.
PD map -> category -> threat model -> protection level -> measures -> perimeter
Inventory
Classification
Threats
Level
Measures
Environment
The protection level is not chosen - it is determined by the input parameters set out in Government Decree No. 1119. Below are the parameters that must be fixed before discussing security controls.
| Input parameter | What we record | Why this changes the security level |
|---|---|---|
| Personal data category | Special, biometric, publicly available, or other categories | Special and biometric data require a stricter level, all else being equal |
| Number of data subjects | More or fewer than 100,000 data subjects who are not the operator's employees | Large-scale processing of third-party data raises the bar for the environment |
| Whose data is it | Operator employees or external parties to the operator | Customer and employee databases fall under different conditions |
| Current threat type | Type 1, 2, or 3 under Resolution 1119, depending on the presence of undocumented capabilities in system or application software | The threat type is defined by the threat model, so it cannot be written after the protection tools have been selected |
The practical meaning of the table: three of the four parameters are about data and processes, not technology. Until it is defined whose data is processed and in what volume, discussing specific protection tools is premature.
The scope of work is assembled for your architecture. We come from the data engineering and integration side, which is usually the part of the environment that remains undocumented.
We review CRM, accounting systems, portals, storage, and integration exchanges and record where personal data is stored, where it comes from, where it goes, and who reads it. The map becomes data, not the knowledge of a single administrator.
We describe threats and the attacker based on the environment that actually works: contractors with access, the integration bus, analytics exports, test environments, and mobile clients.
We gather the PP-1119 input parameters - personal data category, number of data subjects, and type of current threats - and assign the level with a written justification, not by analogy with a neighboring company.
We implement an identity provider and SSO, roles, and an access matrix. Every user, including external contractors, gets a single entry point and an explicit set of permissions, and access revocation becomes a single action.
We configure logs: who accessed which data and when, and what exports were sent outside. This trail supports both regulator inspections and incident notification within the first 24 hours.
We remove personal data from places where it is not needed: anonymization in integrations, masking in test environments, and cleanup of application logs. Data that is not in the system cannot leak.
If language models have appeared in the processes, requests to them go through LLM gateway with the data policy and log, not directly from the application to a third-party cloud.
| System / layer | Scope of responsibility |
|---|---|
| Business process owner | Determines which personal data the process needs and which events are considered unacceptable. Without that decision, there is nothing to benchmark the scope of protection against. |
| Customer's legal domain | Processing grounds, consents, the personal data processing policy, notification to Roskomnadzor about the start of processing, and data processing agreements. |
| The customer's information security and IT teams | Operates the environment every day: users and permissions, updates, incident response, and contractor oversight. |
| KT.Team | A map of personal data and data flows, a threat model tailored to the actual architecture, justification of the protection level, access segmentation and SSO, logging, and data minimization in exchanges. |
| Organization licensed by FSTEC of CIS | Certification of personal data systems and conformity assessment where required by the nature of the system or by contract terms. |
| Roskomnadzor and FSTEC of CIS | Regulator and methodology: requirements, measure set, oversight, and incident response. |
As of May 30, 2025, amendments introduced by Law No. 420-FZ of 30.11.2024 apply to Article 13.11 of the Administrative Offenses Code. The fine for a breach depends on the number of affected data subjects, and a repeat violation turns the fine into a turnover-based penalty: 1% to 3% of annual revenue, but not less than RUB 20 million and not more than RUB 500 million (Part 15 of Article 13.11). Unlawful transfer of biometric personal data costs a legal entity from RUB 15 million to RUB 20 million (Part 17 of Article 13.11).
For business, this changes not the budget line, but the owner of the task. While the fine was fixed and moderate, the risk was handled legally - with documents and procedures. A revenue-based fine is tied to turnover, so it cannot be reserved for in advance, which means the question shifts to those responsible for architecture: where the data is physically stored, who has access to it, and what remains in the log if access falls into the wrong hands.
The deadlines reinforce the same shift. Roskomnadzor must be notified of an incident within 24 hours, and the results of the internal investigation must be reported within 72 hours. Reconstructing within a day what exactly was lost is only possible from a preconfigured log. If there is no log, the company gets a second violation on top of the first, this time for silence.
Cases
Bringing a personal data information system into compliance relies on two engineering essentials: controlled access and explicit data boundaries. Below are projects where we did exactly that, outside the scope of a dedicated GDPR project.
In the single sign-on project for GK TOCHNO, access to related services for internal users took from three weeks to two months to approve, while external contractors had no accounts at all - exchanges were handled on paper and digitized afterward. We implemented Keycloak as the identity provider and the personal account as the single entry point. From the perspective of GDPR, this is the basic part of the perimeter: a clear account for everyone who reads data, and one controlled mechanism for issuing and revoking rights.
In the MDM project for Muztorg, the data boundary was defined at the task-setting stage. The case wording was: "Another boundary is personal data: for the historical load, we intentionally take only legal entities." This is a cheap and underrated move: data that you did not pull into the new perimeter does not need to be protected or explained to the regulator.
We review systems, integrations, and contractors with access. The result is a draft personal data map and a list of places where the data ended up unexpectedly.
We record the category of personal data, the number of data subjects, and the type of actual threats, establish the protection level with justification, and compare it with the measures in Order No. 21.
We break down the gap between required and actual into a short task list and sort it by risk, not by the order of the order's sections.
We implement access controls, logging, and data minimization, document procedures, and hand over the perimeter to the client's team together with diagrams and the decision log.
FAQ
According to Government Decree of the CIS No. 1119 of 01.11.2012. The inputs are the category of personal data being processed, the number of data subjects, the indicator "employees or outsiders," and the type of actual threats taken from the threat model. There are four levels, from UZ-4 to UZ-1. The sequence matters: first the threat model, then the level, and only then the set of measures.
FSTEC of CIS Order No. 21 of 18.02.2013 approves the scope and content of measures to ensure personal data security in personal data information systems. Order No. 17 of 11.02.2013 sets the requirements for protecting information not constituting a state secret in state information systems. If your personal data information system operates within a state information system, both documents apply.
For government information systems, certification is required by GIS regulations. For commercial personal data systems, the issue is determined by the nature of the system and contract terms: public-sector customers and large enterprise clients often require it contractually. The certification itself is carried out by an organization licensed by FSTEC of CIS, and we prepare the perimeter for that process.
The controller's responsibility does not transfer together with the data. Processing on the contractor's side is formalized through a processing assignment, and protection requirements apply to that part of the environment. In practice, this means the personal data map must extend beyond the company perimeter and include everyone receiving data through integrations.
A personal data map and a justified protection level are usually assembled in a few weeks - this is analytical work, not procurement. After that, the timeline depends on the gap between the required and actual state: access segmentation and logging are implemented much faster than rebuilding integrations where personal data is transmitted in plain text.
Not by default. Sending data to an external service is a separate legal act, and a prompt containing a fragment of a customer database involves not one data subject but thousands. The practical setup is a gateway that anonymizes data before sending and keeps logs; the architecture is covered in the article on AI agents and GDPR.
Start with the personal data map. It answers which systems are personal data information systems at all and almost always reveals two or three forgotten places: an analytics export, a test environment with a production database, or a log containing phone numbers.
KT.Team service
We build the personal data map, a threat model tailored to your architecture, and a justified protection level, then close the gap through engineering: access control, logging, and minimizing personal data in exchanges and logs.
