Which GDPR storage limitation duties GLPI helps you meet
If you run GLPI, your help desk, asset and user records probably hold personal data about staff and people who raise requests, and that data should not sit indefinitely. GLPI helps with two storage limitation duties under Regulation (EU) 2016/679 (the GDPR): keeping historical log entries only for a defined period, using the data and privacy settings and the PurgeLogs automatic action, and removing or anonymizing records that no longer need to identify anyone, using the GDPR Tools plugin for inactive users and the Anonymize plugin for irreversible anonymization profiles, mainly in test copies. Those tools execute retention decisions; they do not make them. Retention periods, the lawful basis for each processing activity and whether a particular record must be kept for a legal, contractual or accounting reason all belong to your data protection and legal owners, and they should be written down before you change any setting. Confirm the current retention range and purge behavior in the GLPI 12 data and privacy documentation for your version, since a purge that runs against the wrong period is hard to reverse.
The GDPR itself does not require an audit, attestation or certificate, and DeployOpen does not issue any. What we do is prepare the configuration, the controls and the evidence that your controller or processor obligations are being carried out, such as documented purge periods, a record of who approved them, and test results showing that anonymization ran as intended. Independent auditors and supervisory authorities judge whether the outcome meets the Regulation, and certification under Article 42, where it applies, does not reduce your own responsibility for compliance. Before you rely on these tools, check the GDPR Tools plugin requirement for a GLPI Network Basic subscription and confirm the plugin's support for your GLPI version with the vendor.
A practical starting point is to list every category of personal data GLPI holds, assign each an owner and a retention rule, and map each rule to a setting, an automatic action or a manual procedure. Gaps between that register and the configured behavior are where storage limitation findings usually come from, so treat the first reconciliation as a planned deliverable with sign-off, not a configuration task.
Mapping GDPR retention requirements to GLPI settings
This table maps each GDPR obligation relevant to retention to the GLPI capability that addresses it, the setting to configure and the role that should own the decision. Read each row as a question the controller must answer before configuration starts, since the technical setting only works once the retention value has been set by the business. The main takeaway is that GLPI can enforce retention periods, but it cannot decide what those periods should be.
| Requirement | GLPI capability and setting | Owner who decides the value |
|---|---|---|
| Storage limitation (GDPR Article 5(1)(e)): personal data kept no longer than needed | History log purge under data and privacy settings, from deletion up to 120 months, run by the PurgeLogs automatic action | Data protection officer with the business owner of the ITSM process; record the chosen period in the retention schedule |
| Storage limitation for inactive accounts | GDPR Tools plugin cleaninactiveuser automatic action, which cleans or permanently deletes inactive users; requires a GLPI Network Basic subscription | IT service owner and HR or identity team, agreed with legal counsel on the inactivity trigger and whether deletion or cleaning applies |
| Security of processing (Article 32): appropriate technical measures over personal data | Restrict who can run purges and user deletion through GLPI profiles, and keep the purge configuration under change control | CISO or security lead, with the GLPI administrator who applies the profile |
| Controller accountability (Article 5(2) and Article 24): demonstrate how the retention rule is applied | Document the purge settings, automatic action run history and deletion outcomes as part of the retention evidence pack | Compliance lead, who keeps the record of processing and the evidence for assessors |
| Test copies of production data | Anonymize plugin profiles that apply irreversible anonymization before a copy leaves production | Test environment owner and data protection officer, who approve which fields the profile must transform |
| Irreversibility of anonymized test data | Confirm that the anonymization profile cannot be reversed from the copy, and keep original data out of the test system | Data protection officer, who signs off on the approach and the verification steps |
| Retention of audit trail entries that include personal data | Purge period for history logs may remove records that incident or change investigations still need | Incident response lead and change manager, who agree a period that does not undermine investigations |
| Confirm plugin availability and version before design | Check the GDPR Tools and Anonymize plugin documentation against the GLPI version in use before committing to a design | GLPI platform owner, who confirms the subscription and version with the vendor |
How GLPI history purge periods and PurgeLogs work
The history purge period is the GLPI setting that decides how long historical log entries are kept before they are removed. In GLPI's data and privacy settings you choose a value from immediate deletion up to 120 months, and the PurgeLogs automatic action carries out the purge on its schedule. For a GDPR storage limitation position, this is the control that makes log retention a documented decision rather than an accident of database growth. Before you set the value, decide which log categories must survive for security investigation, contract or financial dispute, and audit, because a short period removes that history for everyone.
The setting has a narrower reach than many teams assume. It governs historical log entries, so it does not, by itself, change the live content of tickets, the current asset records, user profiles or contracts. Retention for those objects is handled through other mechanisms, such as deleting or anonymizing records, and each needs its own decision. Confirm in your own GLPI 12 or 11 instance which data types the history purge period affects, which entries are still written to the database after a purge runs, and whether PurgeLogs is active and running. Test this on a copy first, and record the result as evidence of the retention rule you applied.
Ask your implementation partner or internal team to document three things before go-live: the chosen period for each relevant data category, the owner who approved it, and the verification steps that show the automatic action ran. The official GLPI 12 data and privacy documentation is the natural next read for the exact option list in your version.
Choosing between cleaning, deleting and anonymizing records
Cleaning is the lightest option. The GDPR Tools plugin runs the cleaninactiveuser automatic action against inactive accounts, and in cleaning mode it removes personal details from the user record while the account itself stays in the database. Use this option when you must stop holding personal details about former staff or customers, but older tickets, assets and history still need a user reference. Confirm the exact fields cleaned and the inactivity criterion in your installed version of GDPR Tools before you rely on it.
- Trigger: the
cleaninactiveuserautomatic action, scheduled by GLPI and configured with your inactivity threshold. - What changes: personal details on the account are removed, while the account record remains.
- What stays linked: tickets, assets and history entries that reference the user keep the link, so a requester or assignee reference may still appear. Confirm how your version displays these references.
- Reversibility: treat the run as one-way and take a full database backup beforehand.
- Subscription: GDPR Tools requires a GLPI Network Basic subscription, which should appear in the cost of this option.
Ask your data protection officer whether the remaining linked records still contain personal data that cleaning leaves in place.
Permanent deletion uses the same plugin and automatic action, configured to remove the account record itself. Choose it when no lawful purpose remains for keeping the account and you have checked that removing it will not break links from tickets, assets, contracts or approvals that you must keep. Deletion has the widest effect on related records, so it needs a documented scope before the first run. Confirm the deletion behavior for your version in the GDPR Tools documentation.
- Trigger: the
cleaninactiveuserautomatic action, configured for permanent deletion. - What changes: the user account is permanently removed from GLPI.
- What stays linked: objects that pointed to the user, such as tickets, assigned assets or history entries, may lose the name or reference they show. Test this on a copy before the production run.
- Reversibility: plan the deletion as irreversible. Restoring the account means restoring the database from a backup taken before the run.
- Subscription: GDPR Tools requires a GLPI Network Basic subscription, so include it in the cost comparison with the other options.
Before you enable deletion, confirm the retention period for each record type that refers to users and record the decision with your compliance owner.
Anonymization is meant for non-production copies, such as a test or training instance loaded from production data. The Anonymize plugin applies anonymization profiles that replace personal values with irreversible substitutes. The copy keeps its structure, relationships and volume, so tests behave like production without exposing identifiable people. Review the Anonymize documentation to confirm which fields each profile covers in your version.
- Trigger: running an anonymization profile against the copy, normally after the restore and before any tester signs in.
- What changes: the fields named in the profile are overwritten with irreversible values across the copy.
- What stays linked: relationships between records remain intact, so tickets still point to the right assets and users within the copy.
- Reversibility: anonymized values cannot be restored from the copy. Keep the source backup under its own access controls.
- Scope check: data outside the profile, such as custom fields, attachments or logs, is not changed unless a profile covers it. Confirm this for every field type you hold.
Search the anonymized copy for known personal values before handing it to testers, and record the profile version used for each refresh.
Evidence to keep for auditors and data protection reviewers
A data protection reviewer will ask whether GLPI actually deletes or anonymizes data on the schedule you set, and whether you can show it. The items below are the records that answer that question, and each one depends on the configuration staying as documented.
Configured purge period and change history
The history purge period in GLPI's data and privacy settings sets how long historical log entries are kept, from deletion up to 120 months. Export the current value and keep dated snapshots, so you can show what was configured on any given date. Ask who changed the setting, when, and under which approval. A period that changed without a record is hard to defend, because the reviewer can ask why older entries were still present.
PurgeLogs execution records
The PurgeLogs automatic action is what removes historical entries once the period has passed. Check that the action is scheduled and running, and keep its run history or the relevant logs from the GLPI server. Because the action is what does the deleting, a configured period with no execution record is weak evidence. Confirm how long your server keeps these logs, since they may roll over before your review cycle does.
GDPR Tools run logs and deleted-user lists
The GDPR Tools plugin cleans or permanently deletes inactive users through the cleaninactiveuser automatic action. For each run, keep the criteria used, the date, the operator, and the list of accounts cleaned or deleted, with identifiers rather than personal data where possible. This shows that inactivity rules were applied consistently. Note that the plugin requires a GLPI Network Basic subscription, so confirm the license is active for the period you are reporting on.
Anonymization profile definitions
Anonymize profiles define which fields are replaced and how, and anonymization applied through them is irreversible. Keep a copy of each profile definition with its version and owner, so the reviewer can see exactly which data categories a test copy lost. Record which profile was used on which copy. If a profile is edited later, the old definition should still be retrievable, because the earlier copies were produced under it.
Anonymization run records for test copies
For each database copy sent to a test or training environment, keep a run record showing the source, the date, the profile applied, the operator, and the target environment. Confirm the copy was anonymized before any access was granted. Because anonymization cannot be reversed, the run record is the only proof that personal data was removed from that copy. Store it with the change or ticket that authorized the refresh.
Written retention schedule with approvals
The retention schedule is the document that states, for each data category in GLPI, how long it is kept, what deletes or anonymizes it, and who approved those rules. Keep it under version control, with the approver's sign-off and the date of each revision. Map each rule to the GLPI setting or plugin that enforces it. Auditors and data protection reviewers test whether the schedule matches the running system, so review it against the configuration at least when the GLPI version changes.
Configuring retention in GLPI step by step
This sequence turns a written retention schedule into GLPI settings, scheduled cleanup, test-copy anonymization and backup rules, and leaves dated evidence that each control ran.
Document the retention schedule by data category
Before touching GLPI, list each category of personal data it holds, such as user accounts, ticket content, asset assignments, logs and backups. For each category, record the purpose, the legal basis your privacy team has confirmed, the retention period, the deletion or anonymization method and a named owner. Ask your data protection officer or privacy lead to approve the schedule in writing. The step is done when every category in the GLPI instance has an owner and an approved period, and any category without a period is flagged for a decision rather than left open.
Set the history purge period in data and privacy
In GLPI 12, open the data and privacy settings and set how long historical log entries are kept. The range runs from deletion to 120 months. Translate the approved schedule for log history into one value and record the change in your configuration log, with the administrator who made it and the date. Confirm that the value matches the schedule and that no other setting overrides it for your entities. The step is done when the saved value appears in the settings and the change is in your change record.
Confirm the PurgeLogs automatic action runs
A purge period has no effect unless the PurgeLogs automatic action runs. Open the automatic actions page, locate PurgeLogs, and check its status, last run and any error. Run it manually once on a non-production copy first and review what was removed. Then confirm that the scheduled run is enabled on production and that the cron or task runner that triggers GLPI's automatic actions is operating. Keep a screenshot or export of the action's state. The step is done when a run has completed without errors and the scheduler is confirmed as active.
Install and configure GDPR Tools for inactive users
The GDPR Tools plugin requires a GLPI Network Basic subscription, so confirm the licence and the vendor terms with Teclib' or your reseller before you plan on it. Install the plugin on a test instance first, then configure the inactivity threshold and the choice between cleaning and permanent deletion for inactive users. The cleaninactiveuser automatic action performs the work, so verify its schedule and run it against a test dataset. Record which accounts were affected. The step is done when the plugin's rules match the schedule and the test run's results have been reviewed and signed off by the data owner.
Define anonymization profiles for test copies
Test, training and development copies of GLPI often contain production personal data that does not need to be there. Use the Anonymize plugin to define profiles that replace names, contact details and other identifying fields in those copies. The anonymization is irreversible, so set it only on copies that are never restored into production. Test the profile on a disposable copy, check that the ticket, asset and user relationships still work for testing, and document which fields each profile changes. The step is done when a sample copy has been anonymized, reviewed for remaining identifiers and approved for use.
Align backup retention with the schedule
Backups are copies of the same data, so they fall under the schedule too. Ask your backup owner to set a retention period for database and file backups that matches the approved categories, and to document how expired backups are deleted. Make sure backups include the config directory with glpi.key and glpicrypt.key, because the GLPI update procedure requires those keys, and that they are protected to the same standard as production data. Restore one backup to a test environment to prove the set is usable. The step is done when the backup policy states the retention per category and a restore test has passed.
Re-check retention plugins after each upgrade
The GLPI update procedure requires a backup of the database, files and config directory, replacement of the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Add a post-upgrade check to your change process: confirm that GDPR Tools and Anonymize are active, that their automatic actions are scheduled, and that PurgeLogs still runs with the same settings. The step is done when the post-upgrade checklist is completed and signed by the platform owner.
Capture evidence of each control
Keep a dated evidence file that shows the schedule, the settings export, the PurgeLogs and cleaninactiveuser run records, the anonymization profile and its test result, the backup policy and restore test, and the post-upgrade checks. Assign an owner to review the file on a cadence you set in the privacy programme. Note that DeployOpen prepares this evidence, but GDPR does not require an audit or certificate, and independent assessors judge whether your controls are sufficient. The step is done when the evidence file is complete, indexed and accessible to the data protection officer.
Questions buyers ask about GLPI GDPR retention
What drives the cost of a GLPI GDPR retention configuration?
The main drivers are how many data categories need a retention rule, which GLPI subscription tier you hold, and how many test copies need anonymization. History purge is a built-in setting, so it is usually the least costly part. Cleaning inactive users with the GDPR Tools plugin requires a GLPI Network Basic subscription, which is a recurring license cost paid to Teclib' and separate from any implementation fee. Ask for a written quote that lists each data category, the rule agreed for it, the subscription needed, and whether the work is one-time or recurring.
Can our team configure GLPI retention without a partner?
Yes, many teams can set history purge periods themselves, because GLPI's data and privacy settings are configured in the administration interface and purge runs through the PurgeLogs automatic action. The harder part is the decisions behind the settings: which records are personal data, how long each category is needed, and how deletion is verified across backups and test copies. Teams often bring in a partner for the anonymization profiles, the GDPR Tools rollout and the evidence trail. Confirm your internal capacity against the retention schedule you have agreed.
How long does a GLPI retention project usually take?
Duration depends on scope and environment: the number of data categories, whether GLPI is one instance or several, how many test copies exist, and whether backup retention must be addressed. A single instance with a short list of categories is far smaller than a multi-entity deployment with inherited test databases. No duration is given here because none has been established for this scope. Ask the partner for a timeline in the written scope, with milestones for decisions, configuration, test runs and handover.
What do we need to provide for the work?
You need to provide the retention decisions, meaning how long each category of personal data is kept and what triggers deletion. A data protection officer or legal owner should sign off these decisions before configuration starts. The team also needs administrator access to the GLPI instance, its database and any test environments, plus the ability to confirm backup handling. Without these inputs, the configuration will reflect assumptions rather than your documented policy, so agree the decision record before the build.
Does a retention configuration make us GDPR compliant?
No. The GDPR requires no audit, attestation or certificate, and compliance remains the responsibility of the controller. Configuring purge periods, deleting inactive users and anonymizing test copies supports storage limitation, but it does not cover the whole regulation. DeployOpen prepares systems, controls and evidence for compliance assessments, and does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those roles. Ask your legal team which assessment, if any, applies to your organization.
Can anonymized GLPI test copies still contain personal data?
They can, if the anonymization profile does not cover every table, field and attachment that holds personal data. The Anonymize plugin applies irreversible anonymization profiles, but the scope of each profile must be checked against your own data model and custom fields. Verify the result by sampling records after a run, and confirm that backups or logs copied with the test environment are handled as well. Ask the partner to document which fields each profile changes and how the outcome was tested.
Is GLPI Network Basic required for every retention control?
No. History purge is part of GLPI's data and privacy settings and does not require a GLPI Network subscription. The GDPR Tools plugin, which cleans or permanently deletes inactive users through the cleaninactiveuser automatic action, does need a GLPI Network Basic subscription. Confirm the current licensing terms with Teclib' before you plan, since subscription details can change. Include the subscription cost in your quote comparison as a recurring line item.
How DeployOpen scopes GDPR retention work in GLPI
DeployOpen starts every GDPR retention engagement with a written scope that names each GLPI retention control in play before any configuration changes. In practice that means listing the history purge periods for log entries (set from deletion up to 120 months under the data and privacy settings, purged by the PurgeLogs automatic action), the inactive user cleanup rules for the GDPR Tools plugin, and the anonymization profiles for any test copies. The scope also records which GLPI Network subscription tier covers the plugins, since GDPR Tools requires a Basic subscription. It names the client roles that approve each decision, usually the data protection officer, the GLPI administrators and the system owners, and it states what is out of scope, such as retention of data held in the client's other systems. Quotes follow from this written scope, so the client can compare the work against its own estimate.
DeployOpen then configures these controls inside the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks. The work covers the retention settings, the scheduled automatic actions, a tested restore of a non-production copy before any anonymization run, and a record of each setting and its owner. Every change is validated on a staging copy first, and the outcome is documented so that the client's assessors and independent auditors can trace each rule back to a decision. DeployOpen prepares systems, controls and evidence for these reviews, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies perform those assessments. Retention periods are a legal and business decision, so the client should obtain legal advice before fixing them. This service does not replace that advice.
Retention controls drift after go-live, so DeployOpen also offers retainers for ongoing upgrades and checks. Typical retainer work includes reviewing the purge settings after each GLPI release, confirming that plugins are reactivated after updates, and re-running the anonymization test on refreshed copies. Clients should confirm with DeployOpen which of these checks are included in a retainer and how often they run, since that depends on the agreed scope.
