Data anonymization: when security drives the project

By Amina Belhassena · November 2, 2026

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.

Here's an inside look at the project from Cécile Masson, Business Development Manager, and Amina Belhassena, Solution Architect at ARCAD Software.

Key takeaways

  • 1

    The pilot ran on the client's own data, validating installation, integration and security under real-world conditions.

  • 2

    A single Production server is enough: project autonomy depends on how projects are designed and packaged, not on the number of servers.

  • 3

    Security was the deciding factor: OIDC, Vault and a security assurance plan made the difference.

Background: moving off a costly, outdated solution

The client was using Informatica to anonymize its test data and had already started migrating from Informatica Data Masking. The solution was expensive, and the client's cloud data-hosting policy had kept it stuck on an older version.

Its data landscape was heterogeneous: several databases (SQL Server, MySQL, PostgreSQL), plus flat files to process.

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.

The business challenge: a secure tool

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.

“We absolutely had to match the organization's security level,” explains Cécile. “It was a non-negotiable prerequisite, and it shaped the deal right to the end.” 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.

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.

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? “Our reliability in meeting R&D deadlines, which were regularly tracked and challenged,” says Cécile. 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.

The technical challenge: a tool under control

Constraints driven by architecture and security

On the technical side, the constraints had nothing to do with data volume or performance. They were first and foremost about architecture and security.

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.

“The client wasn't just checking that anonymization worked,” Amina points out. “It wanted to make sure the anonymization tool itself met its security standards.” 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.

A two-tier Design / Production architecture

The chosen solution is built on a two-tier Design / Production architecture. The Design server acts as the master server. It is used to design each project: definition, choice of anonymization engines, and source type. Once validated, the project is exported as a package (.zip archive). 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. It then launches the run, either from the interface or from the command line (CLI).

Transfer of an Anonymization Project via a Package from the Design Server to the Production Server

Transferring an anonymization project as a package from the Design server to the Production server

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.

The approach: 2 validation phases, 3 teams

The project relied on two successive validation phases, each one closer to real-world conditions.

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.

The pilot had two strands. The functional strand covered sensitive data discovery, 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.

Three-Year Project Roadmap

Three-year project timeline

“Starting with a functional sandbox trial, then moving to a heavily security-focused pilot, isn't all that common,” notes Cécile. “But it says a lot about the standards of an organization that keeps raising its security bar to fend off attacks.”

Three teams involved on the client side

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. “We showed that this autonomy didn't depend on the number of servers, but on how projects are designed, packaged and isolated,” explains Amina. In the end, the client opted for a single Production server, cutting costs significantly without giving up a single requirement.

Results: a decision grounded in evidence

The pilot demonstrated:

  • full functional coverage of the client's actual scope, with a single tool for all three DBMSs and flat files;

  • the viability of the Design / Production architecture, including in disconnected mode;

  • compliance with security requirements;

  • integration into the existing IT system (CLI, API, monitoring).

Financially, two factors proved decisive against Informatica. First, a pricing model that isn't tied to data volume. 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.

The client is already looking ahead: adding new DBMSs and new business lines.

Lessons learned: what applies beyond this project

Bring Architecture and Security in from the start. In a cross-functional anonymization project, 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.

Don't confuse autonomy with more servers. With sound management of users, groups and packaged projects, a single Production server is enough to keep projects isolated.

Run the pilot in-house, on your own data. 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.

Design for industrialization from day one. “An anonymization project isn't a one-off job: rules will change and jobs will be rerun,” 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.

To learn more, explore more customer success stories.

Spécialiste en anonymisation

About the author

Amina Belhassena

Solution Architect, ARCAD Software

Holding a Ph.D. in Computer Science and Technology, specializing in Big Data Processing, Amina has spent several years working for companies in the data industry, where she developed extensive expertise in data processing, management, and governance. She joined ARCAD Software in 2024 as a Product Manager before moving into her current role as DOT Solution Architect, where she helps organizations successfully deliver their data anonymization and data sampling projects.

For any question on anonymization, contact our specialists.

TRIAL VERSION / DEMO

Request a trial version or a session in our sandbox!

Trial Version

Test Data Management Expert

Try it now!

Request a trial version

or

Demo

Test Data Management Expert

Personalized demo

Ask our data masking experts