![\"Data](\"https:\/\/www.arcadsoftware.com\/dot\/wp-content\/uploads\/2026\/11\/data-anonymization-security-project.png\")
<\/span><\/div><\/div><\/div>By Amina Belhassena \u00b7 November 2, 2026<\/p>\n<\/div><\/div><\/div><\/div><\/div>
Replacing an existing anonymization solution is rarely just a matter of features. At a major French public-sector group, the project was won on different ground: the tool itself had to meet the organization's security standards.<\/p>\n
Here's an inside look at the project from C\u00e9cile Masson, Business Development Manager, and Amina Belhassena, Solution Architect at ARCAD Software.<\/p>\n<\/div><\/div><\/div>
Key takeaways<\/span><\/p>\n<\/div> The pilot ran on the client's own data, validating installation, integration and security under real-world conditions.<\/p>\n<\/div><\/li> A single Production server is enough: project autonomy depends on how projects are designed and packaged, not on the number of servers.<\/p>\n<\/div><\/li> Security was the deciding factor: OIDC, Vault and a security assurance plan made the difference.<\/p>\n<\/div><\/li><\/ul><\/div><\/div> The client was using Informatica to anonymize its test data and had already started migrating from Informatica Data Masking<\/a>. The solution was expensive, and the client's cloud data-hosting policy had kept it stuck on an older version.<\/p>\n Its data landscape was heterogeneous: several databases (SQL Server, MySQL<\/a>, PostgreSQL<\/a>), plus flat files to process.<\/p>\n ARCAD Software was introduced through an integration partner. It wasn't unfamiliar territory: DOT Anonymizer was already in use at another entity within the group.<\/p>\n<\/div> The need was clearly defined, since the goal was to replace an existing product. The client's Head of Data oversaw all discussions. With business requirements already well understood, the real battle was fought elsewhere.<\/p>\n \u201cWe absolutely had to match the organization's security level,\u201d explains C\u00e9cile. \u201cIt was a non-negotiable prerequisite, and it shaped the deal right to the end.\u201d The client had recently tightened its security policy. DOT Anonymizer offers OIDC authentication and connects to a secrets vault (Vault), two capabilities that made it possible to meet the required standard. The ARCAD Software team also had to produce a security assurance plan.<\/p>\n The second criterion was the IT architecture. For security reasons, the client keeps its business lines strictly isolated from one another. The head of architecture played a key role in getting these constraints across, which allowed ARCAD Software to propose the Production Server: a solution tailored to this architecture, at an acceptable cost.<\/p>\n No competitor was left in the running at the decisive stage: ARCAD Software was the only vendor to make it through both the sandbox and the pilot. What tipped the scales? \u201cOur reliability in meeting R&D deadlines, which were regularly tracked and challenged,\u201d says C\u00e9cile. The product's sovereignty and close access to R&D also counted, at a time of growing distrust of American products. Finally, negotiations were conducted with the client's procurement officer, and the purchase went through a central purchasing body and a distributor.<\/p>\n<\/div> On the technical side, the constraints had nothing to do with data volume or performance. They were first and foremost about architecture and security.<\/p>\n The client wanted anonymization jobs to run as close to the data as possible. It wanted to design, deliver and run each project independently, while keeping infrastructure and licensing costs under control. On top of that came several requirements: centralized authentication via OIDC, credentials retrieved from a Vault rather than stored in the tool, credential hashing, fine-grained user and group management, and log integration into the monitoring system. Finally, other applications had to be able to trigger anonymization on the fly, which meant APIs were a must.<\/p>\n \u201cThe client wasn't just checking that anonymization worked,\u201d Amina points out. \u201cIt wanted to make sure the anonymization tool itself met its security standards.\u201d To give the Security team precise answers, ARCAD Software brought in a group of R&D experts on top of its regular project support. The teams also ran the tests directly in the client's environment rather than relying on generic demos.<\/p>\n<\/div> The chosen solution is built on a two-tier <\/span>Design \/ Production architecture<\/a>. The Design server <\/span>acts as the master server. It is used to design each project: definition, choice of <\/span>anonymization engines<\/a>, and source type. <\/span>Once validated, the project is exported as a package (.zip archive)<\/span>. This package bundles the engines, any Groovy scripts and the source descriptions. A single Production server imports the package and adds connection details if needed<\/span>. It then launches the run, either from the interface or from the command line (CLI).<\/span><\/p>\n<\/div><\/div><\/div> Transferring an anonymization project as a package from the Design server to the Production server<\/p><\/div><\/div><\/div><\/div><\/div> This delivery model brings a twofold benefit. Each project becomes a self-contained deliverable that can be versioned and replayed. And the Production server can run without any direct communication with the Design server, which strengthens isolation. Both connected and disconnected modes were tested so the Architecture team could verify that environments were properly isolated.<\/p>\n<\/div> The project relied on two successive validation phases, each one closer to real-world conditions.<\/p>\n In the first year, the client explored the solution in a sandbox: functional tests run on ARCAD Software's infrastructure with the vendor's own data, without tying up the client's environments or exposing its data. A year later, the client chose to run a pilot on its own infrastructure, using a sample of its own data, since performance wasn't a key criterion.<\/p>\n The pilot had two strands. The functional strand covered sensitive data discovery<\/a>, reuse of the data dictionary, and anonymization of both filtered databases and flat files. The technical and security strand covered server installation, server-to-server communication, project import\/export via the interface, the CLI and the OpenAPI (Swagger) APIs, as well as an in-depth security assessment.<\/p>\n<\/div><\/div><\/div> Three-year project timeline<\/p><\/div><\/div><\/div><\/div><\/div> \u201cStarting with a functional sandbox trial, then moving to a heavily security-focused pilot, isn't all that common,\u201d notes C\u00e9cile. \u201cBut it says a lot about the standards of an organization that keeps raising its security bar to fend off attacks.\u201d<\/p>\n<\/div> Three teams were involved on the client side. The Data team owned the anonymization rules, the Architecture team checked server isolation, and the Security team assessed the tool. The pilot was run as a series of workshops, backed by brainstorming sessions with the architects, and these discussions reshaped the strategy. Initially, the client was considering several execution servers to guarantee project autonomy. \u201cWe showed that this autonomy didn't depend on the number of servers, but on how projects are designed, packaged and isolated,\u201d explains Amina. In the end, the client opted for a single Production server, cutting costs significantly without giving up a single requirement.<\/p>\n<\/div> The pilot demonstrated:<\/span><\/p>\n<\/div> full functional coverage of the client's actual scope, with a single tool for all three DBMSs and flat files;<\/p>\n<\/div><\/li> the viability of the Design \/ Production architecture, including in disconnected mode;<\/p>\n<\/div><\/li> compliance with security requirements;<\/p>\n<\/div><\/li> integration into the existing IT system (CLI, API, monitoring).<\/p>\n<\/div><\/li><\/ul> Financially, two factors proved decisive against Informatica. First, a pricing model that isn't tied to data volume<\/a>. Second, an on-premises installation that keeps data inside the client's infrastructure, which carried as much weight as price. Choosing a single Production server also brought costs down significantly.<\/p>\n The client is already looking ahead: adding new DBMSs and new business lines.<\/p>\n<\/div> Bring Architecture and Security in from the start.<\/strong> In a cross-functional anonymization project<\/a>, the questions that shape everything aren't just functional: Where do jobs run? How are credentials protected? Who has access to what? Tackling them early prevents having to revisit decisions midway. Here, security shaped the deal from start to finish, which echoes the CISO's perspective on anonymization<\/a>.<\/p>\n Don't confuse autonomy with more servers.<\/strong> With sound management of users, groups and packaged projects, a single Production server is enough to keep projects isolated.<\/p>\n Run the pilot in-house, on your own data.<\/strong> Testing anonymization isn't enough: you also need to validate installation, server-to-server communication, tool integration and automation. If performance isn't at stake, a sample is enough to get representative results. That's also the benefit of starting with a limited scope.<\/p>\n Design for industrialization from day one.<\/strong> \u201cAn anonymization project isn't a one-off job: rules will change and jobs will be rerun,\u201d Amina reminds us. Separating Build, handled by the Design server, from Run, handled by the Production server, and designing projects that can be versioned and driven from the command line, sets you up to scale from the very first day. To dig deeper into this model, read our article Design Server and Production Server: Two Pillars of a Modern, Industrialized Anonymization Architecture<\/a>.<\/p>\n To learn more, explore more customer success stories<\/a>.<\/p>\n<\/div><\/div><\/div><\/div><\/div>Background: moving off a costly, outdated solution<\/h2><\/div>
The business challenge: a secure tool<\/h2><\/div>
The technical challenge: a tool under control<\/h2><\/div>
Constraints driven by architecture and security<\/h3><\/div>
A two-tier Design \/ Production architecture<\/h3><\/div>
![\"Transfer](\"https:\/\/www.arcadsoftware.com\/dot\/wp-content\/uploads\/2026\/11\/anonymization-project-transfer-via-package-from-design-server-to-production-server.png\")
<\/span>The approach: 2 validation phases, 3 teams<\/h2><\/div>
![\"Three-Year](\"https:\/\/www.arcadsoftware.com\/dot\/wp-content\/uploads\/2026\/11\/three-year-project-roadmap.png\")
<\/span>Three teams involved on the client side<\/h3><\/div>
Results: a decision grounded in evidence<\/h2><\/div>
Lessons learned: what applies beyond this project<\/h2><\/div>
![\"Sp\u00e9cialiste](\"https:\/\/www.arcadsoftware.fr\/dot\/wp-content\/uploads\/2025\/11\/amina-belhassena-dot.png\")
<\/span><\/div><\/div><\/div>![\"Test](\"https:\/\/www.arcadsoftware.com\/dot\/wp-content\/uploads\/2025\/04\/contact-trial-version.png\")
<\/span><\/div>