Data Masking: 8 Critical Questions Businesses and Developers Ask About Protecting Sensitive Data

Garda expert Dmitry Larin shares insights from the webinar 'Data Masking: Battle of Opinions', answering frequent questions about protecting sensitive information in test and development environments.

Many organizations secure production databases rigorously while leaving test environments exposed. Developers, contractors, and analysts often access real customer names, payment details, and transaction records because test segments receive only basic network controls. Masking addresses this internal threat that encryption cannot fully mitigate once legitimate access is granted.

Encryption of entire databases can severely degrade performance, as seen in one client case where query speeds dropped dramatically. Masking offers a lighter alternative that keeps data in readable text format, enabling deduplication and compression during backups. The two technologies complement each other: encryption protects against external theft while masking controls what internal users see.

Improper masking can break applications if data loses semantic structure. Effective solutions replace real values with synthetic equivalents that preserve formats, indexes, and relationships, allowing applications to function normally. Organizations can also reduce database size for testing while maintaining required scenarios.

Static masking creates fully detached copies for developers or contractors. Dynamic masking intercepts queries in production to return masked results based on user rights. Selective masking targets specific records such as data of former employees, and streaming masking processes high-volume transfers to analytics platforms without latency requirements of dynamic methods.

Regular expressions outperform ML models on structured fields like passport numbers, while machine learning excels at extracting personal data from unstructured text such as call-center comments. Garda Data Masking combines both approaches with manual verification options.

Processing 5 TB of PostgreSQL data can take 14 hours, and copying 5 TB over a gigabit link requires 11-12 hours. Incremental masking, compressed copies, and careful scheduling outside business hours help balance speed and system load. Resource planning is critical, as demonstrated by a 30 TB pilot that failed because the target VM had only 10 TB capacity.

Custom scripts struggle with multiple database types including PostgreSQL and Oracle, schema changes, and custom data formats. Specialized tools allow reusable rules and proper access-right management that scripts cannot provide.