Cloakr · on-premise data masking
Customer data stays in production.
Cloakr creates masked copies of your databases for development, testing and analytics. Names and emails become fake but plausible values, tax codes are masked, IBANs removed, and the relationships between tables stay intact.
| id— | nomeSubstitution | cognomeSubstitution | codice_fiscaleRegex | emailDeterministic | ibanNulling Out |
|---|---|---|---|---|---|
| 1042 | Mario | Rossi | RSSMRA80A01F205X | [email protected] | IT60X0542811101000000123456 |
| 1043 | Giulia | Ferrari | FRRGLI91C45L219K | [email protected] | IT02L1234512345123456789012 |
| 1044 | Paolo | Brambilla | BRMPLA75T12E507R | [email protected] | IT40S0542811101000000654321 |
Each column has its own rule. The id is left untouched, so foreign keys keep working.
PostgreSQL · MySQL · Oracle · SQL Server — installed in your Kubernetes cluster
The problem
The fastest way to get test data is copying production. It's also the riskiest.
Real testing needs realistic data. So a production dump ends up in staging, on a developer's laptop or in an external vendor's environment.
From then on, your customers' personal data lives on systems with fewer controls and more people accessing them. That's exactly what GDPR and ISO 27001 ask you to avoid.
How it works
Three steps, from source to masked copy
- 01
Connect source and destination
Register the production database and the destination one. Cloakr reads the schema and the dependency order between tables.
- 02
Define the masking template
Pick an algorithm for each column, with uniqueness and length constraints. AI suggestions look at the schema only, never at the values.
- 03
Run and review
Run the job on demand, schedule it, or keep it in sync continuously with CDC. Every run has logs, processed rows and an outcome.
Compliance
Where Cloakr fits
Cloakr is a technical measure: it helps meet these requirements, it doesn't replace the work of your DPO or auditor.
| Reference | What it asks | How Cloakr helps |
|---|---|---|
| GDPR Art. 25 | Data protection by design | Masking rules are defined once in a template and applied to every copy, not by hand. |
| GDPR Art. 32(1)(a) | Pseudonymisation as a security measure | Substitution, deterministic hashing, regex and nulling, column by column. |
| GDPR Art. 5(1)(c) | Data minimisation | Copy only the tables and columns the test actually needs. |
| ISO/IEC 27001:2022 A.8.11 | Data masking | Documented, versioned masking policies applied repeatably. |
| ISO/IEC 27001:2022 A.8.33 | Test information | Test environments receive masked data instead of operational data. |
| ISO/IEC 27001:2022 A.8.31 | Separation of environments | Separate source and destination: production isn't exposed to development and testing. |
Note: pseudonymised data is still personal data under GDPR (Recital 26). We help you choose the right technique for each column.
Technical details
What your IT team will ask
- Installation
- Helm chart on Kubernetes 1.24+, inside your network perimeter.
- Databases
- PostgreSQL, MySQL, Oracle, SQL Server.
- Files
- Masking for CSV, XLSX and JSON.
- Algorithms
- Substitution, shuffling, nulling, regex, truncation, deterministic, randomization.
- Integrity
- Loaded in foreign key order, uniqueness and lengths preserved.
- Execution
- On demand, scheduled, or continuous via Change Data Capture.
- Access
- Users and roles with granular permissions.
Let's see it on your data.
Tell us which databases you use and how you build test environments today. You'll hear back from us, not a sales rep.