Data masking: anonymization and pseudonymization
Data masking replaces sensitive values with secure equivalents in data copies for test/dev, analytics, RAG/AI, and sharing with contractors. Anonymization makes it impossible to identify an individual without additional information, pseudonymization preserves reversibility via a separate key, and tokenization moves the original data into a secure perimeter. RESTART detects sensitive data, selects the appropriate method for each scenario, and integrates the rules into the architecture.
Why does business need data masking?
In an enterprise environment, data almost always goes beyond the production system: to test/dev, BI, DWH, Data Lake, RAG, Document AI, service support, contractors, integrators and internal sandboxes. This is where risk most often appears: real customers, employees, payments, contracts, medical information or commercial terms begin to live in environments where there is less control, more copies and a wider range of users.
Masking and anonymization are needed not only to comply with requirements. This is a way to launch releases, AI pilots and analytics faster without the constant manual approval of each upload. A good project answers a simple management question: what data can be safely used, where it needs to be replaced, where it is enough to restrict access, and where real records should not leave production at all.
Key Terms, Plainly Explained
| Term | What does it mean in practice | When to apply |
|---|---|---|
| Data Masking | Replacing sensitive values with safe analogues: part of the number, full name, address, account or contract is hidden or converted. | Test/dev, support, demonstrations, reports, uploads to contractors. |
| Depersonalization | Transformation of personal data so that without additional information it is impossible to identify a specific person. In the Russian context, it is related to Federal Law No. 152-FZ and the requirements of Roskomnadzor. | Analytics, research, data marts, model training, data set sharing. |
| Pseudonymization | Identifiers are replaced by aliases, but the relationship can be restored if a separate key or mapping table is available. | Scenarios where reversibility is needed: investigations, reconciliations, process support. |
| Tokenization | The sensitive value is replaced with a token, and the original is stored in a secure loop. | Payment data, client IDs, integrations, APIs. |
| Synthetic data | Artificially created records that are similar in structure and distribution to real ones, but are not data on specific people. | Development, testing, training, load scenarios, demonstrations. |
Abbreviations that are often found in such projects: PDn - personal data, ISPDn — personal data information system, DWH — corporate data warehouse, BI — business analytics, RAG — Retrieval-Augmented Generation, an approach in which AI responds based on corporate sources, DLP — Data Loss Prevention, leak control, DAM/DBF — Database Activity Monitoring / Database Firewall, monitoring and protection of databases.
Where risks arise
Development and testing
A copy of the production database ends up in a less secure environment, where developers, testers, contractors, and CI/CD processes have access to it.
Analytics and DWH
Data is combined from CRM, ERP, 1C, SAP, personal accounts and file storage. The richer the display case, the higher the risk of re-identification.
AI and RAG
Documents, requests, logs and knowledge base fragments may contain personal data, trade secrets, internal prices, contractual terms and closed regulations.
Contractors and support
An external team often needs realistic data for diagnostics, but does not need real passports, phone numbers, accounts, addresses and personal profiles.
Russian and international practice
In Russia, the basic context is set by Federal Law No. 152-FZ “On Personal Data”, requirements for the protection of ISPDn and orders of the FSTEC of Russia, including FSTEC order No. 21. For depersonalization, it is important to consider Roskomnadzor order No. 140 dated June 19, 2025 on requirements for anonymization of personal data. If the environment relates to critical information infrastructure, Federal Law No. 187-FZ and requirements for CII are added.
Useful in international practice NIST Privacy Framework, NIST SP 800-188 by de-identification, NIST SP 800-122 on PII protection, materials ENISA on pseudonymization And EDPB Guidelines 01/2025. We use these approaches as a practical framework: re-identification risk assessment, data minimization, key separation, access control, auditable procedures and regular review of rules.
What RESTART Delivers
Finding sensitive data
We collect a map of systems, tables, documents, logs, APIs, file storages and data owners. We look separately at production, test/dev, DWH, BI, AI and contractors.
Classifying scenarios
We determine where real data is needed, where masking is sufficient, where pseudonymization, tokenization, depersonalization or a synthetic set is needed.
Designing the rules
We describe fields, conversion algorithms, reversibility, key storage, exceptions, roles, logs, quality criteria and residual risk.
We integrate into the architecture
We prepare HLD/LLD, integrations, roles, regulations, pilot, acceptance, operation and connection with information security, Data, DevSecOps, ERP and AI environments.
AI as an accelerator, not an autopilot
AI can significantly speed up a project: find probable personal data in documents, tables, logs and code; classify fields; highlight the risk of re-identification; propose masking rules; check whether sensitive fragments are included in the RAG index, prompts, responses and logs. In test/dev, AI helps generate synthetic data sets that are similar to real ones in structure and distribution.
But the final decision cannot be left to the model. The rules of transformation, the admissibility of anonymization, residual risk and access mode must be confirmed by data owners, information security, lawyers and architects. RESTART's role is to make AI a useful survey and control tool, rather than a source of uncontrollable legal or architectural conclusions.
Affiliate Technologies
The technology stack depends on the task: static or dynamic masking, tokenization, database protection, DLP, DBF/DAM, user activity control, secure test/dev preparation and integration with existing repositories. RESTART does not start with the selection of one product: first, data, scenarios, risks and architecture are recorded, then an instrumental environment is selected.
DAMASCUS
masking, tokenization, dynamic data protection
Garda
DLP, DBF, Data Masking, NDR, WAF, Anti-DDoS
Partners are listed as the technology backbone of the solution class. The specific composition of products, versions, licenses, certificates and delivery conditions are confirmed before the project.
What does the client get?
| Artifact | Why is it needed? |
|---|---|
| Sensitive Data Card | Shows where personal data, trade secrets, payment and contract data are stored, who the owner is and where they are transferred. |
| Scenario Matrix | Separates production, test/dev, BI, DWH, AI, contractors, support and data exchange by risk level. |
| Conversion rules | They record fields, algorithms, reversibility, keys, exceptions, quality and residual risk. |
| Implementation architecture | Describes HLD/LLD, integrations, roles, logs, loops, pilot, and operations. |
| Evidence pack | Provides an evidence base for information security, audit, compliance and internal audits. |
| Roadmap | Helps you start with the highest-risk and highest-value scenarios without turning the project into an endless inventory. |
First step
A practical start is a short examination of one or two environments: for example, production → test/dev, RAG pilot for corporate documents or a BI/DWH showcase with personal and contract data. At this stage, it is important not to promise “complete anonymization of everything,” but to quickly understand the real flows, fields, owners, risks and limitations.
After the first diagnosis, you can choose a route: masking pilot, test/dev preparation policy, rules for AI/RAG, connecting a vendor solution, finalizing the DWH process, or a full-fledged ISPD protection project.
Testing masking in the laboratory
Masking and anonymization are best tested on a controlled set of data: you need to make sure that business logic is preserved, tests pass, analytics don’t break, and real personal data doesn’t go to test/dev, contractors, or AI scripts. The Information Security Lab helps test these conditions before scaling.
Frequently asked questions
What is data masking?
Replacing sensitive values with secure analogues: part of the number, full name, address, account or contract is hidden or converted, but the structure and business logic of the data are preserved. Used for test/dev, support, demonstrations, reports and uploads to contractors.
How is masking different from depersonalization?
Masking hides or transforms individual values into copies of the data. Depersonalization is the transformation of personal data so that without additional information it is impossible to identify a specific person; in Russia it is associated with Federal Law No. 152-FZ, the requirements of Roskomnadzor and order No. 140 of 06/19/2025. In practice, companies mix these terms, so the design explicitly addresses reversibility, keys, and re-identification risk.
What is pseudonymization?
Identifiers are replaced with pseudonyms, but the link can be restored if a separate key or mapping table is available. This is needed where reversibility is important: investigations, reconciliations, and process support. Tokenization is a similar technique: the value is replaced with a token, while the original is stored in a secure environment.
Why mask data for test/dev and AI?
A copy of the production database ends up in a less secure environment where it becomes accessible to developers, testers, contractors, and CI/CD. In RAG and AI systems, documents, queries, logs, and indexes may contain personal data and trade secrets. Masking enables releases, AI pilots, and analytics to proceed without manual approval for each data export and without real records in these environments; for personal data, this is part of personal data protection under Federal Law No. 152-FZ.
Which data is masked first of all?
Personal data, trade secrets, payment and contractual information: real clients, employees, payments, contracts, medical records, and commercial terms. They start with the riskiest data flows—production → test/dev environments, BI/DWH dashboards containing personal and contractual data, and RAG pilots using corporate documents. Dashboards and layers corporate data warehouse are masked before analytics and AI gain access to them.
Is it possible to start without purchasing DLP or DBF?
Yes. Often the first step is mapping data, scenarios, and risks. After that, it becomes clear whether a separate product is needed, process improvements, role changes, database-level masking, or a combination of measures.
Let's discuss your environment
Describe the task, current systems, constraints, and expected results. We will offer a practical first step: diagnostics, pilot, audit, roadmap or project team.
