GLPI anonymize plugin: safe test and training copies

Why teams anonymize GLPI data before testing with the Anonymize plugin

The Anonymize plugin is the GLPI route for replacing identifying values in a copy of an instance, so that the copy can be used for testing or training without exposing personal details about staff, requesters or internal assets. A team that needs a realistic GLPI instance for an upgrade rehearsal, plugin development or a training program usually holds production data full of names, email addresses, computer owners and entity structures that should not travel to a test server, a laptop or a vendor's support team. Anonymizing a copy lets the team work with data that behaves like production without carrying those identities along.

Teams most often put this step in front of three activities. The first is an upgrade rehearsal before a GLPI 11 or GLPI 12 move, where the copy must match the production schema and plugin set closely enough to expose problems. The second is a training program, where trainees need tickets, assets and users that look plausible but belong to no one real. The third is sharing data with a vendor or a plugin developer who needs a reproduction of a fault. Before adopting the plugin, confirm in its own documentation who publishes it, whether it is Teclib-published or community-maintained, which license applies, and which GLPI versions it supports. Those answers determine who you can ask for help when a rule behaves unexpectedly.

Plan the copy as a controlled environment from the start. Decide which profiles apply to users, entities, computers and email addresses, and test each rule on a disposable copy before running it on anything you intend to keep. Record who approved the anonymized copy and where it is stored, because a copy that still contains identifying fields is a data exposure in its own right. Ask your team to confirm, in writing, which fields the plugin cannot reach so that a manual review covers them before the copy leaves your environment.

What the Anonymize plugin changes in a GLPI copy

A GLPI copy made for testing or training carries the same personal and organizational data as production unless something removes it. The Anonymize plugin replaces values in profiles for users, entities, computers and email, and field-level rules cover the rest. Each card below names one area a team would otherwise expose and what to confirm before running the plugin.

User identity and login data

User records hold names, login names, email addresses, phone numbers and job titles. A test copy that keeps these lets a tester see real staff and can expose sign-in identifiers that match directory accounts. Confirm in the plugin documentation for your version which user fields the profile replaces, whether login names are changed, and what replacement values it uses. Check that the copy cannot send mail to real addresses.

Entity and organization names

Entities show customer, subsidiary and department names, and their hierarchy often reveals how a client or business unit is structured. Anonymizing entities keeps the tree shape needed for testing permissions and reports while replacing the labels. Confirm whether the profile keeps parent and child relationships, whether it renames entity comments or addresses, and how it handles entities used in ticket visibility rules.

Computer and asset records

Computer names, serial numbers, IP addresses, MAC addresses and assigned users appear in inventory and in tickets. These fields can identify internal systems and the people who use them. Confirm which asset fields the computer profile covers, whether serial and network identifiers are replaced consistently across related records, and whether inventory imported later will reintroduce original values.

Email addresses and notifications

Email addresses appear on users, on ticket followups and in mail collector settings. A copy that still holds real mailboxes can send notifications to customers or staff. Confirm whether the email profile changes addresses on users and in notification targets, whether it touches mail collector and SMTP settings, and whether the copy's outbound mail is disabled as a separate step.

Field-level rules for free text

Ticket descriptions, followups, comments and custom fields often hold names, account numbers and incident details that no profile targets by name. Field-level rules let you choose specific fields and replacement behavior. Confirm the exact field list supported in your version, how the rules handle attachments and documents, and whether they can be scoped to a single entity or itemtype before you rely on them.

Changes are permanent

Anonymization rewrites data in the database. The original values are not kept by the plugin, so a copy cannot be restored to production content from the same database. Treat every run as one-way, keep the production backup separate, and plan the controls in the next section before any run. Confirm with the plugin documentation whether any undo or preview option exists in your version.

Why anonymization is permanent and how to protect the copy

Anonymized values cannot be restored from the copy, so the only way back is a fresh copy from backup. Once the Anonymize plugin replaces names, email addresses, computer names or other identifiers in the database, the original values are gone from that instance. Treat every anonymization run as a one-way step and plan the test or training copy so that a bad run costs you a new restore, not production data. The anonymization step must run only on a restored copy that is never the production database. Keep the restored copy on a separate host with its own database credentials, and make the production connection details unreachable from it. Before any run, confirm that the copy's database name and host are the test values, not production's.

Before the first run, apply the controls GLPI's update documentation already requires for safe changes. Take a full backup of the database, the GLPI files and the config directory, and include glpi.key and glpicrypt.key in that backup. Then perform a restore test into an isolated environment and record the result: the date, the backup used, the steps taken, the time to restore and whether GLPI started and returned expected records. A backup that has never been restored is not a control you can show an auditor or rely on during an incident. Ask your team to name who owns the backup, who approves the restore test and where the record is kept.

Encryption keys deserve a separate decision. Copying glpi.key and glpicrypt.key from production into a test instance means that any encrypted credentials stored in the database, such as directory bind passwords, mail server credentials or API tokens, can be decrypted there. Anonymizing user records does not remove those secrets. Decide, before the copy is made, whether the test instance will keep production keys (so that integrations behave like production) or receive new keys (so that stored secrets are unusable and must be re-entered). Also decide how local test accounts, API clients and integration endpoints are disabled or repointed, and who can log in to the copy. Confirm the exact handling of encrypted fields with your GLPI version's documentation and your own restore test before you choose.

Which anonymization profile to apply to each data set

This table compares the main data sets in a GLPI copy, what identifies people or systems in each one, the decision to make and when each choice fits. Read each row before you select a profile, and confirm every option against the Anonymize plugin version you run. The main takeaway is that the safest profile is the one that keeps relations intact while removing the values that point back to real people and systems.

Data set	What identifies people or systems	Decision to make	When the choice fits
Users and login sources	Login names, full names, email addresses, and external identifiers from LDAP or IMAP sources	Replace identities with generic values, or keep accounts but change personal fields	Choose replacement when testers only need working accounts. Confirm whether anonymized users can still authenticate, and check LDAP-linked accounts before selecting this profile.
Entities and their names	Entity names, which often mirror customer, department or site names	Rename entities to neutral labels, or keep names and anonymize only users under them	Rename when entity names reveal a client or organization. Keep names when entity-based rights and visibility must be tested as they run in production.
Computers and inventory names	Hostnames, serial numbers, asset tags, IP addresses and user assignments on assets	Replace hostnames and serials with generated values, or clear assignment fields	Replace when inventory data came from a live network or contains serials that map to purchase records. Confirm whether agent-linked identifiers are affected.
Email addresses and notification targets	Requester and technician addresses, watcher lists, and mail-to-ticket sender fields	Redirect all addresses to a test domain or blank them so no message leaves the copy	Redirect when notifications and email-to-ticket flows must still be tested. Confirm that the copy cannot send mail to real recipients before any queue runs.
Custom field-level rules	Free-text fields, custom fields and comments that may contain names, contract numbers or personal data	Define rules per field, such as masking free text or replacing values with fixed patterns	Use field rules for data the profiles do not cover. Confirm each rule against the field types in your instance, since text inside tickets and follow-ups can still carry personal details.
Structure for tickets, assets and relations	Ticket links, asset relations, item IDs and profile assignments that test workflows and reports	Keep IDs, types and relations unchanged while changing only personal values	Choose this for every copy used in testing. Anonymization that breaks relations makes SLA, approval and reporting tests unreliable.
Test and training copies with reduced access	Remaining data after profiles run, including attachments and logs that the plugin may not change	Decide whether attachments and logs are excluded, purged or restricted to a small test group	Apply this to any copy shared beyond the project team. Confirm how the plugin handles documents and logs for your version before sharing.

How to run anonymization on a GLPI copy, step by step

This sequence turns a production GLPI backup into a safe test or training copy, with each stage leaving a record that a reviewer can check. It is built so the destructive step happens only once the copy is isolated and the rules have been rehearsed.

Confirm plugin and GLPI versions match
Before anything else, the team checks the GLPI release on the copy's source system and the Anonymize plugin build installed for it. The plugin must target the same GLPI major version, and after a major update GLPI suspends plugins until they are reactivated, so the reactivation is confirmed here too. Confirm the exact compatibility of your plugin build with your GLPI version against the plugin's own release notes. The output is a short version record listing the GLPI version, PHP and database versions, and the plugin version with its active state.
Restore a backup into an isolated environment
A platform or GLPI administrator restores the production database and the files directory into a separate server, database and web root that nothing in production can reach. The config directory must be carried over together with the glpi.key and glpicrypt.key files so the restored copy can read its encrypted fields, and the team should confirm this before the first login. The output is a restore log showing the backup source, timestamp, file counts and a successful database load, stored with the copy's ticket.
Cut outbound mail and external connectors
Before the copy starts, the team disables outbound email, notification queues and any connectors that push or pull data from external systems, including inventory agents, LDAP sync, webhooks and the API endpoints used by integrations. Automatic actions on the copy should be paused so that no ticket reminder or survey reaches a real person. The output is a signed connector inventory that lists each integration, the action taken and who verified it, so that the isolation claim can be audited later.
Define anonymization profiles and field rules
A data owner and the GLPI administrator agree which entities, user records, computers and email fields must be changed, and which must stay intact so tests remain realistic. They write profiles for each object type and field-level rules, such as replacing names, login IDs, addresses, serial-related free text and ticket content. The output is a versioned, signed-off rule set with a named approver and a note on what is deliberately kept, reviewed before any data changes.
Rehearse the rules on a throwaway copy
The team runs the approved profiles against a second disposable copy restored from the same backup. Because changes made by the plugin are permanent, this rehearsal is the only safe place to find rules that miss a field, over-match a value or break a relation between tickets and users. The output is a rehearsal report listing the rules run, row counts changed per object type, and any exceptions, which feeds back into the rule set before the real copy is processed.
Run the approved profiles on the working copy
Once the rehearsal report is accepted, the administrator runs the same profiles, in the same order, on the working copy. The run should be performed with a fresh database snapshot taken immediately beforehand, so a mistake in the working copy can be reversed by restoring that snapshot rather than by re-running the restore. The output is a run record with the plugin version, rule set version, start and end times, and the snapshot identifier.
Verify results against a checklist
A second person, not the one who ran the profiles, checks the copy against a written checklist. It covers searches for known production names and email domains, login accounts, computer names and serial patterns, free text on tickets and comments, attachments, and whether ticket-to-user links still resolve. Sample records are reviewed by hand. The output is a signed verification record with the checks passed, any residual findings and the decision to release or rerun the copy for its intended use.
Document the procedure for repeat runs
The team writes down the restore steps, isolation controls, rule set version, rehearsal results and verification checklist as a runbook kept with the rule set. Anyone who runs the process later should be able to repeat it without relying on memory, and the runbook should be updated whenever the GLPI or plugin version changes. The output is a versioned runbook with a change history and the name of the owner responsible for the next run.

What drives anonymization effort and how to keep it down

This table lists the factors that change how much work an anonymized GLPI copy takes, the direction each one pushes effort, and a practical way to reduce it. Use it to scope a partner quote and to decide what your team must prepare before work starts.

Driver	Effect on effort	How to keep it down
Number of entities and users	More entities and users mean more anonymization profiles to design, more records to check and a longer review before owners sign off.	Agree which entities a test copy needs. Anonymize only those, and keep a short list of accounts that must stay recognizable for test logins.
Custom fields and plugin data holding personal information	Each field or plugin table that stores names, phone numbers, addresses or notes needs its own rule. Missed fields are the most common cause of rework.	Export a field inventory from the source instance, mark which fields hold personal data, and ask the partner to confirm coverage for every plugin in use.
Asset names that embed owner names	Names such as laptop names built from a person's name must be rewritten consistently, which adds rules and checks on computers and related items.	Standardize asset naming before the copy is taken, or agree a rule that replaces names with generated identifiers.
LDAP, IMAP or external authentication sources linked to accounts	Linked accounts carry identifiers that can reveal identities. Each source needs a decision on whether links are cleared, replaced or kept for login testing.	List every authentication source and whether test users must sign in. Confirm with the partner how external identifiers are handled before the first run.
History that must remain usable for testing	Keeping tickets, assets and logs realistic while removing personal content takes more rule design and more checks than a stripped copy.	Define the test scenarios first, such as ticket volumes, date ranges and asset types. Keep only the history those scenarios need.
Validation rounds required by data owners	Each round of review by owners, privacy staff or security staff repeats the run and the checks, so effort grows with every round.	Set review criteria in writing before the first run. Give owners a sample export and a checklist so feedback arrives in one consolidated round.
Irreversibility of changes	Anonymization changes data permanently, so a mistake found late means restoring from a backup and running the process again.	Run the first pass only on a restored copy of the source database. Keep the original backup and the glpi.key and glpicrypt.key files as part of the restore set.

Test copy or training copy: what each needs from the anonymization

A test copy exists to behave like production. Upgrades, plugin development and integration testing all depend on relationships between entities, users, computers and tickets, and on volumes that trigger the same code paths as the live instance. The anonymization therefore replaces values that identify people or customers while preserving the structure, identifiers that other systems reference and the record counts that performance and migration tests need. Profiles for users and email usually carry the most weight, because integrations often match accounts by login or address.

Keep relationships intact: Preserve foreign keys, entity hierarchies and the links between users, computers and tickets so that rules and reports behave as they do in production.
Keep identifiers that integrations use: Check whether LDAP, inventory agents, webhooks or the OAuth2 API match on fields such as serial numbers, hostnames or external IDs before you replace them.
Replace personal and customer data: Pseudonymize names, logins, email addresses and free-text fields, and confirm that ticket content and attachments are covered by a rule.
Keep volumes representative: Retain record counts and data shapes so that upgrade and load tests are meaningful, and record which profiles were applied.
Sign-off by the data owner and the platform team: Ask the data owner to approve the scope and the platform team to confirm that integrations still function against the copy.

Before you release a test copy, confirm that the integrations you test against, and the plugins you develop, still resolve the same keys after anonymization.

How anonymized copies connect to authentication, mail and agents

An anonymized GLPI copy is only safe if the systems around it are also contained. Authentication, mail, agents, plugin licensing and backups each can reintroduce production data or contact real people. Check each one before the copy first starts.

Authentication order and test logins

GLPI tries authentication sources in a fixed order: the internal database, then LDAP directories, then IMAP mail servers, then other external methods such as REMOTE_USER. After anonymization, names and login IDs change, so a user who signs in through LDAP may match a different account or fail to match at all. Decide whether test users should authenticate locally, confirm which sources are still enabled in the copy, and test a login for each profile before handing the copy to testers.

Outbound mail and notification queues

A copy that still holds the production mail configuration can send ticket notifications, satisfaction surveys or reminders to real users and customers. Queued notifications created before the copy was taken may also be delivered after the restore. Disable or redirect outbound SMTP, empty the notification queue, and confirm that any test mailbox receives every message type you expect.

GLPI Agent inventory from production endpoints

Agents installed on production computers keep reporting to the server address they were configured with. If that address is reachable from the test environment, or if agents are later pointed at the copy by mistake, real hardware and software inventory can flow back in and overwrite anonymized records. Check agent server URLs, block production endpoints from reaching the copy network, and confirm that the copy does not run inventory tasks against live networks.

Marketplace and plugin licensing for Anonymize

Plugins in GLPI are installed and licensed separately from the core, and the license terms for the Anonymize plugin determine whether you can run it on a copy, in a test environment or in a separate instance. Confirm with the publisher which marketplace registration, license tier and plugin version apply to each environment before you install it on the copy. Plugin versions also need to match the GLPI release in use.

Backups and retention outside the copy

Anonymizing the live database does not remove personal data from backups, exports, log files, file attachments or the config directory kept by the production team. Check where production backups are stored, who can restore them into a test system, and how long they are retained. Treat any restore used to build a copy as a new source of personal data that needs its own controls.

Questions teams ask before anonymizing GLPI data

Can our team run the Anonymize plugin ourselves?

Yes, if your team has someone comfortable with GLPI administration, the database and a restore process. The plugin is configured through GLPI itself, so the work is less about installing code and more about deciding what to change and proving the copy is right. Teams that do this in-house usually still need a clear rule set, a restore environment they can destroy and rebuild, and a second person to check the result before the copy leaves the building. DeployOpen can plan and run the work as a fixed-scope engagement, or hand over a documented procedure your team repeats. Ask which option fits your staff before you commit.

What do we need to provide before the work starts?

Three things matter most. First, a restore environment: a copy of your production GLPI database and files that can be altered without risk, on infrastructure isolated from production. Second, the plugin documentation for the version you run, so the configuration matches what the plugin actually supports. Third, named data owners who decide which fields are personal, which entities and computers are sensitive, and who signs off on the result. Without the sign-off step, nobody can say the copy is ready for use. Confirm access to these items early, because they usually set the pace of the first week.

How long does anonymizing a GLPI copy take?

Scope drives the duration. The number of entities, user profiles, computers, email fields and custom fields you need to cover, the number of sensitive rules, and the number of test cycles before sign-off all add time. Data volume and how many plugins hold personal data also matter, because each one may need its own rules. Ask for a schedule tied to a written list of data categories and deliverables rather than a single number, and ask what happens if your data owners change a rule late in the process.

What does anonymization cost, and what should a quote include?

Cost comes from the people doing the work: analysis of your data, configuration of the anonymization profiles, verification queries, documentation and the review cycles with your owners. Most of the cost is one-time for the first copy. Recurring cost appears when you refresh training or test copies, or when a plugin or GLPI upgrade requires the rules to be checked again. A quote should list the data categories in scope, the environments covered, the deliverables (rule set, verification report, runbook), the review rounds included, and what is excluded, such as custom plugins or third-party integrations. DeployOpen does not publish a price list, so the written scope is the basis for any figure.

Does anonymizing GLPI data make our copy compliant with regulations?

No. Anonymization reduces the personal data in a copy, but whether the copy meets a regulation depends on your legal basis, your data handling policies and the auditor's assessment. DeployOpen prepares controls, configuration and evidence, such as rule documentation, verification results and a runbook, that your assessors can review. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ask your legal and compliance leads to confirm which obligations apply to test and training copies in your jurisdiction.

What happens to the anonymized copy after a GLPI upgrade or plugin change?

The copy does not stay valid by default. Anonymization changes are permanent in the copy, so a new copy must be produced from a fresh restore whenever the data model changes. After a GLPI update, the update procedure requires backing up the database, files and the config directory, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Anonymize rules that depend on a plugin version need re-testing before reuse. Plan a verification pass after each upgrade, and confirm with the plugin documentation which rules still apply to the new version.

How DeployOpen scopes and delivers GLPI anonymization work

DeployOpen plans and delivers anonymized GLPI copies inside infrastructure you control, starting from a written scope that names which data classes, entities and fields are in and out. Because anonymization changes data permanently, we treat every copy as a controlled deliverable with its own verification and handover record.

How we scope

Inventory which entities, users, computers and email fields hold personal data and which copies the business actually needs
Agree the target use for each copy, such as developer testing, training or support reproduction, before any rule is written
Record the scope in writing as a fixed-scope agreement, with the source instance, target environment and deliverables named

How we build

Design anonymization profiles and field-level rules, then run them against a disposable copy of the GLPI database first
Test that foreign keys, logins, notifications and ticket history still behave as expected in the anonymized copy
Confirm the source database is backed up and restorable before any run that changes data, since the changes cannot be reversed

How we hand over

Document each profile, the rules applied, the run order and the checks performed, so your team can repeat the process
Deliver the copy to the environment you specify, with access restricted to the people approved for test or training use
Record which controls the copy relies on, such as separate credentials and network isolation, so reviewers can trace the handling

How we support

Offer ongoing support and repeat anonymization runs as a retainer when refreshed copies are needed on a schedule
Review rule changes when GLPI or the Anonymize plugin is upgraded, including the plugin versions matched to your GLPI release
Ask for a quote based on the written scope, with the number of copies, data classes and environments confirmed up front

Anonymizing GLPI data with the Anonymize plugin