Self-hosted TOPdesk alternative for data sovereignty

For public bodies and regulated organizations that must control where service desk data sits, this page compares regional TOPdesk SaaS with GLPI or Zammad run in their own or a national provider's data center.

On this page

Is a self-hosted TOPdesk alternative the answer to data sovereignty?

A public body or regulated organization that must prove where service desk data is stored, accessed and transferred can meet that requirement with a self-hosted GLPI or Zammad running in its own data center or in a national provider's facility. The answer depends on more than the application, though. Hosting, operator access and backups must be controlled too, because a sovereign application running on infrastructure that a foreign operator can reach, or with backups copied to a foreign cloud, does not give the organization the control it needs. Each of these three layers should be written down as a named owner, a location and an access list before any migration decision is made.

TOPdesk hosts every SaaS region on Microsoft Azure, so the first step is to ask TOPdesk in writing which regional options exist for your tenant, where each one runs, where backups are kept, and which sub-processors touch the data, including support staff who may view tickets from outside the region. Under EDPB Guidelines 05/2021, remote access from a third country, even only displaying data on a screen for support, counts as a transfer, so the support model belongs in the review as well as storage. Ask for the answers as a dated document you can attach to your records of processing.

Under the Data Act, customers have a right to switch to on-premises ICT infrastructure, and switching charges are banned from 12 January 2027, which strengthens your negotiating position if the TOPdesk answers are unsatisfactory. Self-hosting moves the sovereignty work to your side: you will need to document the data center, the administrator accounts with access to the database and the glpi.key or Zammad secrets, the encrypted backup location and the restore test. Involve your data protection officer and your legal team early, since the choice of host determines whether the review ends with a short memo or a long exception.

What data sovereignty requires from a service desk

For a service desk, data sovereignty comes down to where tickets, attachments and personal data sit, and who can reach them from outside the EEA. The cards below set out the transfer rules that apply, the access paths that trigger them, and the switching rights that keep an exit open.

Transfers to third countries

Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet the conditions in Chapter V. Service desk records often hold names, contact details, device owners and free-text complaints, so they count as personal data. Ask your provider where each tier runs, which sub-processors touch tickets, and which country each one operates from. Map those answers against your records of processing before you sign.

Remote access counts as a transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration. This matters for vendor engineers who troubleshoot a hosted desk from abroad. Ask for a written list of which support staff can open production data, from which locations, and under what logging. Self-hosting lets you decide those access paths yourself.

Storage outside the EEA

The same guidelines treat storage in a cloud outside the EEA as a transfer. A regional SaaS tier can still keep backups, search indexes, logs or attachment stores in another jurisdiction, so the region name alone does not settle the question. Ask for the location of every replica, backup and log store, including disaster recovery sites. For a self-hosted GLPI or Zammad installation, you choose the data center and can keep every store inside it.

Fines under Article 83(5)(c)

Infringements of the transfer rules in Articles 44 to 49 fall in the higher fine tier under Article 83(5)(c), with fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. The exposure sits with the controller, so a processor's hosting choice becomes your compliance problem. Record the transfer assessment for each service desk tier, including the data flows and the safeguards you relied on.

Switching rights under the Data Act

The EU Data Act, applicable since 12 September 2025, gives customers the right to move from a data processing service to another provider or to on-premises ICT infrastructure. Articles 25, 29 and 50 set a maximum two-month notice period, a 30-day transition and a ban on switching charges from 12 January 2027. Check the contract for the export format, the notice terms and any exit fees that apply before that date, so the switching right is usable when you need it.

Where regional TOPdesk SaaS meets these requirements and where it does not

A regional TOPdesk SaaS tenancy can keep service desk data in a region you choose, but a region is only one layer of control. Your data still sits on infrastructure run by TOPdesk's hosting provider, Microsoft Azure, and TOPdesk's own support staff, and possibly other sub-processors, can reach it. For a public body or regulated organization, the question is not only where the data is stored but who can read it, from where, and under which legal order. The research behind this page does not establish which regions TOPdesk offers, where its support staff are located, or whether support engineers access tenant data remotely. Those are the facts that decide whether a regional SaaS tenancy meets your requirement, so confirm them before you rely on it.

Ask TOPdesk for written answers to a short list of questions. Request the list of Azure regions available for your tenancy and confirm the region where your data, backups and logs are stored, including any replica or disaster recovery copy. Ask for the current sub-processor list with each processor's location and function, and for notice of changes. Ask where support and operations staff are based, whether any of them can view customer data from a third country, and how remote support sessions are authorized, logged and time-limited. Ask who approves such access and whether the customer can require approval or disable it. Ask how TOPdesk responds to a request from a non-EU authority for your data, and whether it commits to notifying you and challenging overbroad requests.

Treat the written answers as inputs to your transfer assessment rather than as proof of compliance. The EDPB Guidelines 05/2021 treat remote access from a third country as a transfer even when data is only displayed on a screen, so a support session from outside the EEA matters as much as the storage region. If a provider's answers leave gaps, you carry the assessment, and a self-hosted GLPI or Zammad instance in your own or a national provider's data center removes the vendor-side access path. Record the answers, the date and the person who gave them, because your auditors and data protection officer will ask for them.

Which open-source options keep service desk data under your control

This table compares GLPI and Zammad on licensing, sovereignty fit, runtime requirements, optional components and ITSM scope. Read it as a shortlist filter: the rows that matter most for data sovereignty are license, hosting model and database stack, while the scope row decides which platform fits your service desk work.

CriterionGLPIZammad
LicenseGPL-3.0, free to run without a license feeAGPLv3, free to run without a license fee; source owned by the Zammad Foundation
Sovereignty fitSelf-hosted in your own or a national provider's data center, with no vendor-operated SaaS requiredSelf-hosted in your own or a national provider's data center; Zammad GmbH's hosted plans run in German data centers if you choose them
Application runtimePHP 8.3 or later, per the GLPI README; the installation docs list PHP 8.2 or later for GLPI 11.0Ruby on Rails application, deployed as package, Docker Compose or Kubernetes Helm chart
Database and cacheMariaDB 10.11 or later, or MySQL 8.0 or later; only MySQL and MariaDB are supportedPostgreSQL 15 or newer, with Redis 7 or newer for realtime websocket communication
Optional componentsGLPI Agent for inventory and discovery, from the GLPI Agent documentationElasticsearch for search and attachment content (strongly recommended, optional); Memcached for multi-instance deployments
ITSM scopeIncident, problem, change, service level, asset, configuration, knowledge base and contract managementStrongest on ticketing channels: email, chat and portal, plus knowledge base and reporting; limited asset and change coverage
Current major releaseGLPI 12.0.0, published October 7, 2026Zammad 7.2 as the current minor line, with security releases in both 6.5 and 7.x
Best fitIT, asset and change-heavy service desks that need ITIL process coverageCustomer-facing or departmental ticket desks where channels matter more than asset records

Choosing a hosting location for sovereign service desk data

Running GLPI or Zammad in your own data center keeps the operating staff, the hypervisors, the storage and the database under your organization's direct control. Your platform or IT operations team installs the application, configures the web server and reverse proxy, runs the database and handles backups, patching and upgrades. Administrative access sits with people you employ or contract under your own agreements, and no third country can reach the data through a provider unless your own staff or contractors are compelled to act.

  • Operations: Your team owns the application tier, the database tier and the update procedure. For GLPI, that includes the glpi.key and glpicrypt.key files, which must be backed up with the database and config directory.
  • Access: Administrative and root access stays with named internal staff. Ask who holds console, database and backup credentials, and whether any vendor support is granted remote access.
  • Jurisdiction: Your own facility is usually in one country, which simplifies the analysis. Confirm where backup copies and disaster recovery sites are located, since they can fall outside your intended jurisdiction.
  • Cost: Hardware, facility space, power, redundancy and on-call staffing recur. A support contract for Zammad or a GLPI Network subscription is optional and is paid separately.
  • Skills: Confirm your team can meet the PHP, MariaDB or PostgreSQL, Redis and search requirements, and maintain them through each release.

Check that your own data center certifications and internal controls cover the service desk system and its backups, not only the facility.

Deploying a self-hosted TOPdesk alternative under sovereignty rules

This sequence turns a data sovereignty requirement into a running GLPI or Zammad service in your chosen jurisdiction, with written location rules, access controls, tested backups and an upgrade routine that keeps the service under your control.

  1. Write data classification and location rules

    Your data protection or information security lead lists which service desk data is personal data, which is confidential, and which is public, then records in writing where each class may be stored, processed and accessed from. Include tickets, attachments, asset records, LDAP and mail credentials, and backups. Ask your legal team to confirm the transfer analysis for any provider, including whether a provider subject to third-country law could be compelled to disclose data. The step is done when a signed document names permitted countries or data centers and the people allowed to approve exceptions.

  2. Select the hosting environment

    Choose between your own data center, a national or EU-based provider, or a private cloud account that you control, and confirm in writing that the provider cannot give third-country parties remote access to the platform. Ask the provider where backups are replicated, who holds administrative credentials, and which law governs their support staff. Record the decision and the justification against the location rules from the previous step. Done when the chosen environment is approved and the network path for users, administrators and the mail server is documented.

  3. Size the servers and database

    Size the application server, database and file storage from your expected agent count, asset volume and attachment size, then confirm the platform requirements for your release. GLPI 12.0.0 lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later on its main branch, while the installation documentation for GLPI 11.0 lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, so confirm which version you deploy. Zammad requires PostgreSQL 15 or newer. Done when a test build meets your response time target and the database engine is one your team can patch and restore.

  4. Configure the web server and reverse proxy

    For GLPI, point the web server document root at the public directory inside the installation, not the installation root, and enable URL rewriting so requests route through index.php on Apache, Nginx, lighttpd or IIS. For Zammad, place Nginx or Apache in front of the application as a reverse proxy and terminate TLS there. Confirm that directories holding configuration and keys are not reachable from a browser. Done when an external scan or a manual request to configuration paths returns no content and the application loads over HTTPS.

  5. Set up Redis and optional Elasticsearch

    For Zammad, install Redis 7 or newer for realtime websocket communication and decide on Elasticsearch. Elasticsearch is optional, but Zammad recommends it for faster search, reporting and searching the content of email attachments, so decide based on search needs and the data classification from step one. If you run multiple Zammad instances, such as containers or cluster nodes, plan Memcached as well. GLPI does not need these components for its core function. Done when the services are reachable only from the application tier and a test search returns expected results.

  6. Restrict administrative and remote support access

    Limit administrative consoles, database ports and SSH to approved management networks, and require multi-factor authentication for every administrator account. Write down which vendor or support staff may connect and from which countries, because EDPB guidance treats remote viewing of data from a third country as a transfer. Enable session review where the platform supports it, and in GLPI 12.0.0 confirm the active session view and step-up authentication for sensitive administrative actions. Done when a firewall rule set and an access log review procedure are approved and tested.

  7. Configure authentication order

    For GLPI, the user documentation describes authentication against the internal database, LDAP directories, IMAP mail servers and external methods such as REMOTE_USER, tried in that order, so set LDAP as the primary source and keep a documented local administrator for recovery. For Zammad, configure SAML or OpenID Connect with your identity provider, and confirm that local login is restricted to break-glass accounts. Test a user who exists only in your directory and an administrator who loses access to the identity provider. Done when both login paths work and the fallback is recorded.

  8. Test backup and restore in the same jurisdiction

    Back up the database, the files and the configuration directory, including the glpi.key and glpicrypt.key files for GLPI, and confirm that the backup target sits inside the jurisdiction from step one. Restore the backup to a separate system in the same location and confirm that tickets, attachments, assets and logins work. Keep the encryption keys with the backup set so the restore is complete. Done when a restore test has been timed, documented and signed off by the service owner.

  9. Plan upgrades and plugin reactivation

    Schedule upgrades using the GLPI update procedure: back up the database, files and configuration directory, replace the application files, and run php bin/console db:update. Note that since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so test plugin behavior in a staging copy first. For Zammad, track both the 6.5 and 7.x security lines because security releases were published in parallel, and subscribe to the release notes. Done when a staging upgrade runs cleanly and a named owner is responsible for each patch cycle.

How foreign access laws affect the choice of operator

The operator you choose determines which foreign laws can reach your service desk data, so assess that exposure before you sign anything. EDPB Recommendations 01/2020 state that where a cloud provider must access data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption you hold the keys to helps, but it does not remove the problem when the provider's staff must read tickets to run the service. That is why the question is about who controls the operator, not only where the servers sit.

Several instruments matter for an EU operator under foreign control. The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever that data is stored. Article 48 of the GDPR limits how a third-country court or authority order can be enforced in the EU: it must rest on an international agreement in force, such as a mutual legal assistance treaty. Commission Implementing Decision (EU) 2023/1795 covers transfers to US organizations on the Data Privacy Framework List, but an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P, so confirm the status of that case with your counsel before relying on it. Article 32 of the Data Act (Regulation (EU) 2023/2854) also obliges data processing service providers to prevent third-country governmental access to non-personal data held in the Union where that would conflict with EU or national law.

Our conclusion is that an EU operator under foreign-law control must be assessed before engagement. Ask the candidate operator for its corporate ownership chain, the jurisdictions where its staff can access your environment, and how it has handled government access requests. Record the answers in your transfer assessment. This is a legal question with consequences under the GDPR fines regime, so take legal advice on your own exposure and the type of data you hold. DeployOpen does not provide legal opinions or issue attestations on this question.

Evidence regulators and auditors ask for under data sovereignty

A sovereignty review asks where service desk data sits, who can reach it, how it is copied and restored, and how it changes over time. The cards below group the records that answer those questions for a self-hosted GLPI or Zammad deployment. DeployOpen prepares this evidence with you, but it does not issue audit reports or certifications; independent auditors and certification bodies make those determinations.

Data location register

A register that names every system holding service desk data, the country and facility where each one runs, and the copies kept in backups, logs and search indexes. For a self-hosted GLPI or Zammad instance, include the database (PostgreSQL for Zammad, MariaDB or MySQL for GLPI), file storage for attachments, and the optional Elasticsearch index that holds attachment text. Confirm with your provider that no replica or support tooling sits outside the jurisdiction you named.

Transfer assessments and processor contracts

Where any third party, including a hosting provider, a support firm or a national cloud operator, can view or administer the system, record the transfer analysis and the contract terms that govern it. Remote access from a third country counts as a transfer even when data is only displayed on screen. Record who was assessed, the legal basis, and the supplementary measures chosen, and confirm the assessment with your data protection officer or counsel.

Access list by location

A current list of every named administrator and support account, the location each person connects from, the method used (VPN, bastion host or jump server), and the date access was last reviewed. GLPI authenticates users against its internal database, LDAP or IMAP, tried in that order, so record which source is authoritative for each account. Zammad supports SAML, OpenID Connect and other third-party login, which should be listed alongside.

Backup and restore records

Evidence that backups are stored and restored inside the jurisdiction, with the date, scope and outcome of each restore test. For GLPI, the update guidance requires a database backup, a file backup and copies of the config directory including glpi.key and glpicrypt.key; without those keys, encrypted values may not be recoverable. Ask your team to show that the restored instance decrypts stored credentials.

Upgrade and patch log

A dated log of every version change, the source of the release, and the backup taken before it. Zammad published security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, and 6.5.5 on 15 October 2026 for the older line, so state which line you run and how quickly each fix was applied. For GLPI, record plugin reactivation after major updates, because since GLPI 11.0 plugins are suspended after a new version is detected.

Exit plan under Data Act switching rights

A written plan for moving data out if the provider or hosting arrangement changes. The EU Data Act gives customers the right to switch from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and bans switching charges from 12 January 2027. Map which export formats each candidate target accepts, and test an export before you need it. Confirm with counsel which provisions apply to your specific service.

What does a self-hosted TOPdesk alternative cost to run for sovereignty?

Do GLPI or Zammad cost anything to license when self-hosted?

Neither product charges a license fee for self-hosted use. GLPI is free software under GPL-3.0, and Zammad is licensed under AGPLv3, so the software itself carries no per-agent subscription. Two optional paid items can appear in a budget. GLPI Network is Teclib's managed offering, with a public cloud price of 19 euros per user per month, a private cloud price of 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic) to 4,500 euros per month (Enterprise), according to the GLPI Network subscriptions page. Zammad sells self-hosted support subscriptions named Business at 2,999 euros per year, Enterprise at 5,999 euros per year and Corporation at 9,999 euros per year, according to the Zammad pricing page. Both are optional. Confirm current prices with each vendor before you budget.

What recurring costs remain after a self-hosted service desk goes live?

The recurring costs move from the vendor to your own budget. They cover the servers or virtual machines for the application, database, cache and search tiers, storage and backup infrastructure, operating system and security patching, application upgrades, and the staff time to run them. For GLPI, the update procedure requires a database, file and configuration backup before each upgrade, and plugins are suspended after a new version is detected. For Zammad, the stack typically includes PostgreSQL, Redis and optionally Elasticsearch, so each component adds hosting and maintenance. Ask any provider you hire to itemize these recurring items in the quote, and state who performs each one after handover.

How much effort does a one-time data copy from TOPdesk take?

The effort depends on how much history you keep, how many attachments exist, and how cleanly incidents, changes, assets and persons map to the target objects. The migration work includes requesting a data copy from TOPdesk, downloading attachments, mapping records, and importing through a spreadsheet or the API. Zammad's built-in migrators cover other systems but not TOPdesk, so a TOPdesk move to Zammad usually needs custom import work. For GLPI, the mapping is generally more involved for asset and change data. Ask for the effort to be estimated per object type in writing, and confirm with TOPdesk Support what export format and backup window apply to your contract.

Can our internal team run the migration and hosting without outside help?

Some teams can, particularly those with Linux, PHP or PostgreSQL experience and a clear list of data to move. The skills that matter most are web server and database administration, backup and restore testing, identity integration, and change control for upgrades. GLPI's installation docs require a web server pointing at the public directory with URL rewriting, and MariaDB or MySQL only. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer. Assess your team against these components honestly, and decide whether a fixed-scope engagement covering planning, hardening, backup, documentation and handover is worth the cost compared with staff time spent on the same work.

How long does a fixed-scope engagement take to agree and deliver?

DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope. The timeline depends on the number of data sources, the volume of attachments, the number of integrations such as LDAP, SAML or OpenID Connect, and the sovereignty evidence your auditors need. No general duration can be stated without that information. Ask for a written scope with milestones for hosting build, data copy, validation, cutover and post-go-live support, and confirm the acceptance criteria for each one before signing.

What drives the total cost of a sovereign self-hosted service desk up or down?

Five factors shape the total most. The first is the number of agents and end users, which affects sizing and, if you buy GLPI Network, the per-user price. The second is data volume and attachment history, which affects storage, backup windows and migration effort. The third is the hosting choice, whether your own data center, a national provider or an air-gapped network, each carrying different facility costs. The fourth is integration depth, such as directory sync, mail and asset inventory agents. The fifth is the support level you choose, from self-supported to a paid vendor subscription or a retainer. Request a quote that prices each of these separately so you can change one factor without re-quoting the whole project.

What should we request in a quote for a sovereign GLPI or Zammad move?

Ask for a written quote that separates one-time work from recurring work. The one-time items should list architecture and hosting build, data export and migration, mapping decisions, testing, security hardening, documentation and training. The recurring items should list hosting, backup and restore testing, upgrades, support hours and any retainer for ongoing testing. Also request the assumptions behind each number, such as the agent count, data volume and hosting location, and ask who owns the backups, configuration keys and administrator credentials at handover. Confirm the hosting location in writing if data residency is part of the decision.

How DeployOpen deploys under data sovereignty requirements

The first decision is where the service desk database, attachments and mail relay will physically run, and who holds administrative access to each layer. DeployOpen starts from that map. We plan the target in your own cloud account, a national provider's data center or an air-gapped network, then document each component: the GLPI web tier, the MariaDB or MySQL database, the file storage for uploads and the glpi.key and glpicrypt.key files, which must be backed up with the rest of the config directory. For Zammad the equivalent set is PostgreSQL, Redis, the optional Elasticsearch index and, for multi-instance deployments, Memcached. Each one is a place where ticket content can leave your control if it is left to a default setting, so each one gets a named owner and a location.

Remote support is the control most often missed. Under the EDPB's Guidelines 05/2021, a vendor or integrator viewing data on a screen from a third country is itself a transfer, so DeployOpen's access model is written into the scope before work starts: named engineers, jump hosts inside your environment, session recording where your policy requires it, and access that ends when the change window closes. Ask us to confirm where each support engineer works and which jurisdictions their access passes through. Also ask for the contract terms on sub-processors, including any hosting or log tooling we would use during the engagement, and the Article 48 position on disclosure requests.

Plan for exit at the same time as entry. The Data Act gives customers the right to switch providers or move to on-premises infrastructure, and that right also helps you assess a hosting partner: confirm in writing that you can take the database dump, attachments and configuration without a fee, and that the runbook is yours. DeployOpen delivers the architecture, hardening notes, backup and restore procedures and upgrade documentation as client-owned artifacts, so an audit or a change of partner does not depend on us. Compliance readiness means preparing controls and evidence for your assessors; the certification or audit opinion is issued by the independent auditor, not by DeployOpen.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.