turnover-based fine for a repeat personal data leak
Since 30 May 2025, a first leak carries a fine of up to RUB 15 million; a repeat leak, 1–3% of revenue — from RUB 20 million to RUB 500 million.
420-FZ of 30 November 2024OpenDSPM · data security
Know where your personal data lives and who can see it — before a leak, not after.
OpenDSPM scans databases and storages and finds passports, SNILS and INN numbers (Russian social insurance and tax IDs), card numbers — 69 data types in all. It scores risk under 152-FZ (Russian personal data law) and 187-FZ (critical information infrastructure law) and shows who has access. You see what to close first — before an audit and before a leak. It runs on your own server and needs no GPU.
● on-prem · no GPU
● SSO OIDC
● alerts → SIEM · CEF · LEEF
data catalogue · examplescanning
pg · crm.public.customersRussian passport · SNILS ✓
mysql · billing.paymentscard number · Luhn ✓
s3://exports/clients.csvINN ✓ · full name
kafka · orders.eventsRussian phone
analytics_ro → billing.paymentsexcess right → REVOKE
152-FZDecree 1119187-FZGOST R 57580.1
✓ 0–100 risk under 152-FZ and 187-FZincremental
69data types out of the box — from Russian passports and SNILS to IBAN
8storage types — from PostgreSQL and ClickHouse to Kafka and S3
31standards and ~250 requirements in the catalogue — from 152-FZ to PCI DSS
24 hto notify Roskomnadzor (RKN, the data protection regulator) of a leak — the deadline under 152-FZ
Interface
This is OpenDSPM at work
Data catalogue: where personal and payment data lives, who can access it and which rights to revoke first.
Demo data.
Why now
Fines now scale with revenue. “We didn’t know it held personal data” is no longer a defence.
Personal data spreads across production databases, analytics, queues and S3 exports, while access rights pile up for years. After an incident, the regulator asks specific questions: what data, where it lives, who had access. You need those answers before a leak.
to notify RKN of a leak
Investigation results are due within 72 hours. Without a data map, you can’t say within a day whose data was affected or how much of it.
152-FZ, Article 21, Part 3.1from 119 databases of Russian companies
Leaked between January and September 2026. The global average cost of a single breach is $4.99M.
F6, iXBT, 13 October 2026 · IBM, 29 July 2026How it works
Storages → data catalogue → access and risk → action.
01
Connect
Connect PostgreSQL, MySQL, ClickHouse, MongoDB, Kafka, Redis, Elasticsearch and S3 — and, in S3, CSV, Parquet, JSON, Excel and other files.
02
Classify
Patterns, dictionaries, checksums and neural entity recognition find 69 data types and sort them into 4 sensitivity levels.
03
Access and risk
For every object: who can access it and a 0–100 risk score — impact × likelihood, adjusted for 152-FZ and 187-FZ.
04
Act
Revoke excess rights directly in the source (preview), use the requirements catalogue for audits, send events to SIEM and email, and tasks to Jira.
Capabilities
More than “personal data found”: a clear place to start and a clear list of what to close.
69 data types with checksum validation
Russian passports, including international passports with MRZ, SNILS, INN, card numbers, IBAN, Russian phone numbers, full names and driving licences. INN, SNILS, cards (Luhn algorithm), IBAN, CPF and CNPJ are validated against their checksums — fewer false positives on random strings of digits.
Patterns, dictionaries and neural networks
Patterns and dictionaries catch structured data; neural named-entity recognition (Presidio + spaCy, GLiNER) finds names and other data in free text in Russian, English and Portuguese. AI classification is in preview.
Databases, queues, search and files
PostgreSQL, MySQL, ClickHouse, MongoDB, Kafka, Redis, Elasticsearch and S3 — and, in S3, CSV, JSON/JSONL, Parquet, Avro, ORC, XML, Excel and text. Repeat scans are incremental, based on schema, row count, modification time and checksums.
Who can see sensitive data
Access-rights analysis across all storages except MongoDB (Elasticsearch requires X-Pack security enabled), plus 7 types of access risk. In PostgreSQL, MySQL and ClickHouse, excess rights are revoked directly from the platform (preview).
A 0–100 risk score shows where to start
An impact × likelihood score for every object, with multipliers when the data falls under 152-FZ or 187-FZ. You know which tables and exports to close first.
Catalogue: 31 standards and ~250 requirements
152-FZ, Government Decree 1119, FSTEC Order No. 21, 187-FZ, GOST R 57580.1 (financial-sector security standard), plus GDPR, PCI DSS, ISO 27001, HIPAA, SOC 2 and NIST CSF — a foundation for audit preparation. Not a legal opinion.
Find a data subject’s records on request
Shows which storages hold a specific person’s data, so you can answer a data subject request with facts, not memory. The platform cannot delete data on request — that is done in the source systems.
Events go where they get handled
14 event types to webhook, Slack, Teams, SIEM (HTTP or syslog; JSON, CEF, LEEF with HMAC signature), email and Jira.
Roles, single sign-on and an append-only log
8 roles and 92 permissions, custom roles, OIDC sign-in. The audit log is append-only — protected by database triggers and exportable to JSON, CSV and syslog. Values are masked in the UI and in API responses.
Who it’s for
The DPO gets a data map. Security gets risk and access. IT gets exactly what to fix.
DPOs and personal data officers
Which personal data is stored where, sensitivity levels, 152-FZ and Decree 1119 requirements in the catalogue, and data subject lookups on request.
CISOs and security teams
A 0–100 risk score for every object, who can access sensitive data, 7 types of access risk, events in SIEM and an immutable action log.
DBAs and IT
The exact tables and accounts with excess rights, rights revocation in PostgreSQL, MySQL and ClickHouse (preview), automated database security checks and tasks in Jira.
Deployment
One install command. One server. No GPU.
- Installation
- A single command,
sudo ./dspm-linux-amd64 install --license X.lic; the licence comes as a file - Operations
- Installer commands
doctor,upgrade,rollback,backup,restore - Server
- Ubuntu 24.04 or 26.04, amd64, Docker Compose. Memory: 8 GB minimum, 16 GB recommended; disk: 20 GB minimum, 40 GB recommended. No GPU needed
- Storages
- PostgreSQL, MySQL, ClickHouse, MongoDB, Kafka, Redis, Elasticsearch, S3; access-rights analysis for all except MongoDB (Elasticsearch with X-Pack security)
- Files in S3
- CSV, JSON/JSONL, Parquet, Avro, ORC, XML, Excel, text
- Database checks
- A catalogue of 58 database security controls, 18 of them automated
- Sign-in and roles
- SSO via OIDC (PKCE); 8 roles — admin, ciso, dpo, security_analyst, dba, auditor, it_engineer, viewer — 92 permissions and custom roles; workspaces and projects
- Audit and integrations
- Append-only log, export to JSON, CSV, syslog; alerts to webhook, Slack, Teams, SIEM (HTTP, syslog; JSON, CEF, LEEF with HMAC signature), email, Jira
- In preview
- Rights revocation in the source (PostgreSQL, MySQL, ClickHouse), AI classification, data lineage, access monitoring
30-day pilot
In a month: a report on where personal data lives and who has excess access.
We agree on success criteria before we start. From you: a server inside your perimeter, access to the storages and named owners from security, the DPO’s office and your database administrators.
STEP 01
Scope
We choose the storages and success criteria together with your security, DPO and IT teams.
STEP 02
Install
We deploy on your server with a single installer command — in one day.
STEP 03 · 30 DAYS
Pilot
We scan your data in observation mode: no rights are changed in the sources.
STEP 04
Decision
A report on where personal data lives, who has excess access and what to close first — and a decision on rollout.
The pilot needs a server with at least 8 GB of memory and 20 GB of disk (16 GB and 40 GB recommended); no GPU needed.
Questions
What DPOs, security and IT teams usually ask
Which storages are supported?
PostgreSQL, MySQL, ClickHouse, MongoDB, Kafka, Redis, Elasticsearch and S3. Access rights are analysed in all of them except MongoDB, and in Elasticsearch only with X-Pack security enabled. SMB/NFS file shares, SharePoint and Microsoft 365, cloud services and Snowflake are not supported today — we’ll check your infrastructure against this before the pilot.
Will OpenDSPM change database rights on its own?
Revoking excess rights directly in the source is available for PostgreSQL, MySQL and ClickHouse, and the feature is still in preview. During the pilot we don’t change any rights: we work in observation mode, and system owners decide what to revoke and when.
Does OpenDSPM mask data in the database itself?
No. Masking applies in the platform UI and in API responses: staff see what was found and where without unnecessary exposure of values. Data in the source stays as it is.
Does this guarantee 152-FZ compliance?
No — and it’s better to say so up front. The catalogue of 31 standards and ~250 requirements helps you prepare for an audit and show where data lives and who can access it, but it is not a legal opinion. Compliance conclusions are for your lawyers and DPO to make.
How long does a scan take, and will it load production databases?
We start with the storages we’ve agreed on. Timing depends on data volume, the number of storages and their load, so we don’t quote figures in advance — we measure them in the pilot on your data. Repeat scans are incremental: the platform compares schema, row count, modification time and checksums.
Can it run in a network without internet access?
OpenDSPM installs and runs on your server. A fully air-gapped environment as a supported mode — with updates and the full lifecycle — is not something we claim today. If you need it, we’ll discuss the requirements before the pilot.
We already have DLP — why OpenDSPM?
DLP watches data in transit. OpenDSPM shows where data sits in databases and storages and who has excess access to it — exactly what the regulator will ask about after an incident.
Do you have an FSTEC certificate?
No. For audits, there is a requirements catalogue covering 152-FZ, Decree 1119, FSTEC Order No. 21, 187-FZ and GOST R 57580.1, plus an append-only audit log.
OpenDSPM pilot
See personal data and excess access in your own data — not on a demo stand.
Submit a request — we’ll agree on the storages for the pilot, the owners and the success criteria.
Request sent
We’ll contact you at the email you provided to arrange your OpenDSPM pilot.
Other OpenZTA platforms