Why EU data sovereignty changes the helpdesk build for your organization
A helpdesk can be run under EU control by self-hosting it in EU infrastructure, but hosting location alone does not settle the exposure. Under the EDPB Guidelines 05/2021 (version 2.0), remote access from a third country counts as a transfer even when the person only views data on a screen for support or administration, and so does storage in a cloud outside the EEA. For an organization moving off a US-hosted helpdesk, the hosting decision therefore includes a second question: who can administer the system, from where, and under which law. Support engineers, vendor troubleshooting sessions and managed-service operators working from outside the EEA can each create a transfer that Article 44 of the GDPR requires to meet Chapter V conditions. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).
Start by mapping every party with administrative or support access to the ticket database, the attachment store, the search index and the backups, and record the country each one works from. Then check whether any operator or hosting provider is subject to third-country law with extraterritorial reach, such as the US CLOUD Act at 18 U.S.C. 2713. The EDPB guidance notes that using an EU processor subject to such law is not itself a transfer, but complying with a third-country authority request would be, so this exposure should be assessed before the contract is signed. Confirm these points in writing with any hosting or support provider, and make the answers part of the processor agreement.
Zammad fits the broadest set of sovereignty requirements because it is AGPL-3.0 licensed, can be installed in your own EU data center or cloud account, and supports the PostgreSQL, Redis and Elasticsearch components that keep all ticket content inside your environment. FreeScout and osTicket fit smaller teams that need a shared inbox with fewer moving parts. Whichever platform you choose, the build decisions that matter most are where the database and attachments sit, who holds administrator rights, and how remote support is granted and logged.
Which EU and US rules decide where ticket data may be stored and accessed
This table maps each EU and US rule that touches helpdesk data to a concrete design choice for where the database, attachments, backups and administrator access sit. Read each row as a question to answer before choosing a hosting model, because the same ticket can be exposed through storage, remote support sessions or a vendor's own access path.
| Requirement | Source | What it means for the build |
|---|---|---|
| Transfers to third countries, including onward transfers | GDPR Article 44 and Chapter V | Map every location where tickets, attachments and backups are stored or viewed, including subprocessors. Any country outside the EEA without an adequacy basis needs a transfer mechanism and a documented assessment before go-live. |
| Remote access from outside the EEA counts as a transfer | EDPB Guidelines 05/2021 (version 2.0) | Screen-sharing or support sessions from a non-EEA vendor engineer can be a transfer even when no data is copied. Restrict vendor break-glass access to EEA staff or require approval and logging for each session. |
| EU processors subject to foreign law | EDPB Guidelines 05/2021, Example 12 | Using an EU-based processor is not itself a transfer, but complying with a foreign authority request would be. Assess that exposure of the hosting provider before signing and document the result for the record of processing. |
| Third-country disclosure orders | GDPR Article 48 | A foreign court order is only recognized in the EU when it rests on an international agreement such as a mutual legal assistance treaty. Keep encryption keys under your control and define in the contract how such requests are challenged and logged. |
| US provider reach under the CLOUD Act | 18 U.S.C. 2713 | US-headquartered hosts must preserve or disclose data in their control even when it sits in Europe. For tickets that require strict EU control, prefer self-hosting in your own EU tenancy with no US-controlled administrator or support account. |
| Schrems II and the Privacy Shield outcome | CJEU Case C-311/18, 16 July 2020 | Privacy Shield was invalidated while standard contractual clauses stayed valid. Standard contractual clauses still need a transfer impact assessment for each US-linked service, including backups and monitoring tools that receive ticket content. |
| EU-US Data Privacy Framework and pending appeal | Decision (EU) 2023/1795; Case C-703/25 P | The framework only covers US organizations on the Data Privacy Framework List, and an appeal is pending. Ask each vendor for its certification status and build a fallback path, such as EU hosting, that does not depend on the framework. |
| Non-personal data held in the EU | Data Act Article 32, Regulation (EU) 2023/2854 | Providers must take measures against third-country access to non-personal data where it conflicts with EU or national law. Ask hosts how logs, metrics and ticket metadata that are not personal data are protected from such access. |
| Switching away from a hosted helpdesk | Data Act Articles 25, 29 and 50 | Customers may move to another provider or on-premises infrastructure with defined notice and transition periods, and switching charges are banned from 12 January 2027. Keep exports of tickets, attachments and audit history in open formats so the move does not depend on the vendor. |
Self-hosting versus EU-hosted plans: which option keeps control
With self-hosting, Zammad runs in your own EU cloud account or data center, so your organization decides who operates the stack and who holds database and administrator access. Zammad is licensed under AGPL-3.0, and self-hosted use carries no license fee, so the recurring costs are infrastructure, staff time and any optional support subscription.
- Operator: Your platform team, or a partner working inside your environment, installs, patches and upgrades the application, PostgreSQL 15 or newer and Redis 7 or newer.
- Administrator and database access: Your own identity controls and change management govern who can reach the database, the server and the admin console.
- Backups and attachments: They sit on storage you select and place in the EU, so the backup location is your decision and your evidence to produce.
- Remote support: Any vendor or partner session is access you grant for a defined purpose, so write the approval, session recording and removal steps into the engagement terms.
- Government access exposure: Your exposure depends mainly on the cloud or data center provider you choose, so assess that provider's jurisdiction, its contracts and any US parent company under Article 48 and the CLOUD Act.
Confirm who will apply security releases such as Zammad 7.2.2, published on 8 October 2026, and check the terms of any Zammad pricing support subscription before you buy one.
An EU-hosted plan moves daily operations to a vendor that runs Zammad on infrastructure in the EU. Your team still manages tenants, agents and configuration, but control now depends on the contract: who at the vendor can reach data, where copies sit, and what support sessions can touch. An EU server location is necessary to check, but it does not settle the transfer question on its own.
- Operator: The vendor's staff run the stack, including upgrades, monitoring and incident response.
- Administrator and database access: Ask which vendor roles can read the database or attachments, under what approval, and with what logging you can export.
- Backups and attachments: Confirm the region of primary storage, backups, replicas and search indexes, along with every subprocessor, including any located outside the EEA.
- Remote support: Under EDPB Guidelines 05/2021, remote access from a third country is a transfer, even when the support engineer only displays data on a screen.
- Government access exposure: The EDPB's Example 12 says an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be, so assess the vendor and its parent before engaging them.
Get the hosting location, subprocessor list, access model, backup region and government request process in writing, and confirm that the data processing terms match your assessment.
A US-hosted SaaS helpdesk places tickets, attachments and agent access under a US provider's operations. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and breaches of Articles 44 to 49 can draw fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). The transfer basis, whether the Data Privacy Framework or standard contractual clauses, must be documented before go-live.
- Operator: The provider runs the stack, sets the upgrade schedule and controls incident response.
- Administrator and database access: Provider staff hold privileged access, so your control is contractual and limited to what the provider logs and reports.
- Backups and attachments: These are often stored in the provider's regions, so confirm whether EU-only storage is available and at what scope.
- Remote support: Provider engineers who view your data from outside the EU create a transfer, which must be covered in your assessment.
- Government access exposure: The CLOUD Act provision at 18 U.S.C. 2713 reaches US providers' data regardless of location, and the Data Privacy Framework adequacy decision is under appeal as Case C-703/25 P.
Before accepting, request the transfer mechanism, subprocessor list, EU-only storage option and the provider's documented process for handling government requests.
Which open-source helpdesk fits an EU sovereignty brief
Three open-source helpdesks are common shortlist candidates for an EU sovereignty brief. Each can run in your own cloud account or data center, but they differ in footprint, migration tooling and how much verification your team must do before committing. The checks below focus on where customer data sits, who can reach it and what evidence each product gives you.
Zammad as the full-featured option
Zammad is licensed under AGPL-3.0, which matters if you modify the software and offer it to users over a network. Its stack is PostgreSQL 15 or newer, Redis 7 for realtime updates and a reverse proxy such as Nginx or Apache. Elasticsearch is optional but recommended for search and for finding text inside email attachments, so attachment content stays on your infrastructure only if you host that index yourself. Multi-instance deployments need Memcached. Check that your hosting, backups and search index all sit inside the EU boundary you have defined.
Zammad release cadence and patching
Zammad 7.2 was released on 23 September 2026 as a minor release, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026. Security release 6.5.5 followed on 15 October 2026, so fixes were published for both the 6.5 and 7.x lines. If you run an older line, confirm which branch your team patches and how quickly you can apply security releases, because an unpatched helpdesk holding personal data is an Article 32 exposure in its own right.
Zammad deployment and identity options
Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. Its Kubernetes support covers only the Zammad application, so cluster operations, storage classes and network policy remain your responsibility or your partner's. For access control, Zammad supports SAML and OpenID Connect, which lets you keep agent login under your EU identity provider. Confirm that the identity provider, MFA and session logs are also hosted in scope for the sovereignty brief.
FreeScout as a lighter footprint
FreeScout is licensed under AGPL-3.0, and version 1.8.248 was published on October 17, 2026. It is a shared-inbox style helpdesk with a smaller operational footprint than a full ticketing platform, which can suit a small EU team that wants to host the service itself. The risk is that a smaller project may offer fewer built-in controls for retention, access logging and data subject request handling. Ask for the current release notes and test retention deletion, audit logging and attachment storage location against your brief before choosing it.
osTicket as the simplest footprint
osTicket is licensed under GPL-2.0, and version v1.18.4 was published on June 17, 2026. It is the lightest of the three in operational terms, which reduces the number of components that must be hardened and patched. The risk for a regulated EU customer base is that core features such as erasure of ticket history, granular role separation and migration from a US-hosted SaaS may need custom work. Confirm each of these against the current documentation and get a written test of erasure before you rely on it.
Verifying sovereignty features before selection
None of the three products should be selected on licensing alone. For each candidate, confirm where attachments, logs and search indexes are stored, whether any telemetry or update channel leaves the EU, how ticket history can be exported for access requests and how erasure reaches backups. Ask your implementation partner to document these answers in writing and to test them in your environment. Keep a record of the release you tested so the evidence still matches the version you run.
How GDPR access and erasure requests reach ticket history
A data subject request that arrives as a ticket is only answered completely if you find every copy of the customer's data, and in a helpdesk those copies sit in more places than the ticket view suggests. The ticket body and email headers are the obvious stores. Attachments are stored as files, their extracted text may be indexed, the customer profile holds identifiers and contact details, agent notes often contain free-text personal details, and the search index and backups hold further copies. Before any request is handled, map each of these stores for your Zammad instance and record who owns it and how it is queried. Zammad's documentation describes Elasticsearch as optional but strongly recommended for search, and notes that it is used for searching email attachment content, so an index populated from attachments is a store you must include in the search and erasure scope if you run it.
Backups deserve a deliberate decision rather than an assumption. A deleted ticket is still present in backup sets until those sets expire, so your retention schedule for backups, and your procedure for restoring a backup that contains an erased record, both need to be written down and tested. Confirm with Zammad which deletion and anonymization functions exist in the release you run, whether they remove or only mask attachment content and search entries, and how they treat audit history and ticket metadata. Ask the same questions of any add-on or custom script your team or partner builds for bulk handling. Access requests have the mirror problem: an export is only complete if it covers the profile, the tickets, the attachments and the notes together.
Erasure also conflicts with records you may be obliged to keep. A ticket that documents a complaint, a payment dispute or a regulated communication may need to be retained for a defined period, and the GDPR does not require you to erase data where another legal basis for retention applies. Decide, per queue and per ticket type, which data is erased, which is pseudonymized, and which is retained with an explicit justification, and record that decision. For the identity checks, the one-month response rule and the handling of requests that arrive as tickets, see the GDPR data subject requests hub as the next read, which covers that workflow in full.
How a migration off a US-hosted helpdesk runs in phases
The sequence moves customer conversations from a US-hosted helpdesk into EU infrastructure you control, with a documented transfer decision, tested access and erasure procedures and a runbook your team can operate after handover.
Scope and map the data inventory
DeployOpen works with your support leads and privacy team to list every channel (email, web form, chat, phone integrations), user and agent group, attachment store, custom ticket field and retention class in the current tool. The output is a written data inventory that names each data category, where it is held today, which vendor and region operate it and which team owns it. The step is done when the privacy owner signs off that nothing in scope is missing, and the signed scope is attached to the fixed-scope agreement.
Assess transfers and record hosting decisions
Using the inventory, your legal and privacy team decides where each store will live: primary database, search index, cache, attachments, backups and any support or remote access paths the vendor retains. For each store the team records whether a transfer to a third country occurs today, whether the current vendor or any sub-processor can be compelled by non-EU authorities, and what contractual or technical measures apply. The output is a transfer assessment record with one documented decision per store, which becomes the reference for the rest of the project.
Build the EU infrastructure stack
DeployOpen builds the target environment inside your chosen EU accounts or data centers, normally with PostgreSQL 15 or newer for content, Redis 7 or newer for realtime websocket traffic, Elasticsearch for search and attachment indexing, a reverse proxy (Nginx or Apache), and Memcached if you run multiple application instances. Backup jobs, restore tests, monitoring and access controls are configured alongside. The output is a deployed staging environment and a restore test record showing that a backup can be recovered within the agreed targets. Confirm the exact topology and any Kubernetes support scope in the written scope.
Migrate data through supported paths
Where the source is Freshdesk, Kayako, OTRS or Zendesk, Zammad's included migrators are the first option. For other systems, DeployOpen maps fields and imports through the Zammad API or through custom development, and verifies the result on a copy. Attachments, user identities, organizations, ticket states and history are checked against record counts and sampled tickets. The output is a migration report listing counts, exceptions and the sample results that the support lead has accepted.
Run in parallel and cut over mailboxes
Before go-live, the team runs the new helpdesk alongside the old one for a period agreed in the scope, with test mailboxes and a limited set of live queues. Cutover then changes DNS records, mail forwarding and channel integrations in a planned order, with a rollback path documented for each change. The output is a tested cutover plan with an owner for each DNS and forwarding change, and a post-cutover check confirming that inbound messages land in the new system and that outbound replies are delivered correctly.
Test access and erasure procedures
Before the old platform is closed, your privacy team tests the procedures a data subject request will follow in the new system: locating a person's tickets across channels and attachments, producing an access export, and erasing or restricting records where erasure applies, including search index entries and backups according to your retention rules. Each test uses a known test identity. The output is a test log with results, defects fixed and a signed procedure that privacy staff can repeat without DeployOpen.
Hand over runbooks and patch process
DeployOpen hands over operational runbooks covering backups, restores, user and channel administration, monitoring, incident response and upgrades. A patch process is agreed for security releases, such as the Zammad 7.2.2 security release published on October 8, 2026, with named owners, test steps on staging and a maximum window your team sets. The output is an accepted runbook set and a patch calendar, and the handover is complete when your team has performed one supervised restore and one supervised update. Ongoing support is available as a retainer.
What a regulator or auditor asks to see from the helpdesk
This table lists the evidence items a supervisory authority or independent auditor is likely to request about a self-hosted Zammad helpdesk handling EU customer data, what each item shows and which component or team produces it. DeployOpen prepares this evidence, but independent auditors and supervisory authorities make the assessment, so use the table as a checklist to confirm with your own assessor before the first review.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| Transfer mapping and hosting decision record | Which personal data flows leave the EEA, under which Chapter V mechanism, and why the hosting choice was made, including any EU-hosted plan assessed for third-country law exposure | Your data protection team, with DeployOpen supplying the architecture and hosting inventory |
| Location register for ticket data, attachments, search indexes and backups | Every place customer content is stored, including PostgreSQL, file storage, Elasticsearch, Memcached or cache layers, and backup targets, with the country and operator for each | Infrastructure configuration, backup tool inventory and the Zammad deployment record |
| Access logs and administrator access records | Who opened, changed or exported tickets, and who used administrator or console access to the host, database and object storage | Zammad audit and activity logs, reverse proxy logs, operating system and database audit logs |
| Records of erasure and access requests and their handling | Each data subject request received as a ticket, the identity check, the decision, the actions taken across ticket history and attachments, and the response date | Zammad ticket history for the request, the request register kept by your privacy team, and deletion logs |
| Configuration evidence for SAML or OpenID Connect login | That agents authenticate through your identity provider, with the configured provider, enforced settings and who can change them | Zammad third-party authentication settings, identity provider configuration export and change records |
| Security update history for 7.2.1, 7.2.2 and 6.5.5 | When each security release was assessed, tested in a non-production environment, applied and verified, and which installed version was running on each date | Change tickets, deployment records, version checks on each instance and the Zammad releases page as the reference |
| Vendor support access logs | When any Zammad vendor or DeployOpen engineer accessed the system, the scope, the approval and the session record, so third-country remote access is visible | Privileged access tool logs, support ticket approvals and VPN or bastion session records |
What EU sovereignty helpdesk work costs and needs from your team
What drives the cost of an EU sovereignty helpdesk project?
The cost depends on scope more than on the software, because the Zammad, FreeScout and osTicket code bases carry no license fee when self-hosted. The main cost drivers are the number of channels you connect (email, web form, chat, phone), the volume and age of ticket history to migrate, the number of stores that must stay in the EU (database, search index, attachment storage, backups, logs), the complexity of migrating from a US-hosted helpdesk, and the support tier you choose. Recurring costs include your hosting, storage, backups, patching and any vendor support subscription. For Zammad, the self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. Ask any partner for a quote that separates one-time work (design, migration, configuration, testing) from recurring operations and subscriptions.
Can our team run an EU helpdesk migration without outside help?
Yes, if you have people who can operate PostgreSQL, a Redis service, a reverse proxy and container or package deployments, and who can run a tested migration. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart, and it includes migrators for Freshdesk, Kayako, OTRS and Zendesk, but other sources require the API or custom development. Most teams underestimate the parts that are not software: mapping agent roles and SLAs, rebuilding automations, testing email routing and deciding what history to keep. A common middle path is to keep the build in-house and buy a fixed-scope partner review of the architecture, migration plan and security configuration. Confirm that your staff can own patching, since Zammad has shipped security releases on several lines in the same weeks.
How long does an EU helpdesk migration take, and what sets the timeline?
No duration is fixed by the platform, so the timeline is set by scope and by the decisions your organization has not yet made. The factors that lengthen the work are the number of sources to migrate, the amount of attachment data, the number of channels and mailboxes, the number of queues and automations to rebuild, the need for SSO integration, and the time legal and security teams need to approve the hosting design. Parallel running for cutover and a sign-off period for test results also add time. Ask any partner for a written plan with phases, acceptance criteria and dependencies, and check that it covers a rollback path for the period when both helpdesks run.
What does legal, security and operations need to contribute?
Each function owns a different part of the decision. Legal should map where personal data is processed and stored, confirm the controller and processor roles, review the contract terms for any hosting provider, and maintain the record of processing and the response procedure for data subject requests. Security should define the hosting boundary, identity and role model, encryption and key handling, logging, backup protection and the patch process. Operations should own backups and restore testing, monitoring, capacity planning, reverse proxy and certificate management, and the upgrade calendar. Agree on a single owner for the helpdesk who can sign off decisions across all three, because gaps usually appear between the functions.
Does self-hosting remove the need for a GDPR transfer assessment?
Not automatically. Self-hosting inside the EEA removes the transfer question only for the parts that stay in the EEA and under your control. The EDPB Guidelines 05/2021 (version 2.0) state that remote access from a third country, even only displaying data on a screen for support, is a transfer, and so is storage in a cloud outside the EEA. Those points apply to vendor support staff as well as to hosting. The same guidelines say that using an EU processor subject to third-country law with extraterritorial effect is not in itself a transfer, but complying with a third-country authority request would be, so you should assess that exposure before engaging such a processor. Map every access path, including backups and support tooling, and record the assessment.
What is the financial exposure if a transfer is not handled correctly?
Under GDPR Article 83(5)(c), infringements of the transfer rules in Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. The exposure is the reason many buyers ask for a documented transfer map before go-live rather than after an incident. Note that the fine figure is a ceiling set by regulation, not an estimate of what any organization would pay. Cite the regulation text on EUR-Lex when briefing executives, and ask your legal team to confirm how the ceiling applies to your sector and to your own processing roles.
Which support tier should we choose for a self-hosted helpdesk?
Choose the tier by the time you need to resolve a production fault, not by the feature list. Self-hosted Zammad has no license fee, and the vendor's subscriptions are priced as Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. Confirm in writing what each tier includes, such as response times, escalation paths, security release notification and upgrade help, because these terms vary. Note that on Kubernetes, Zammad support covers the application only, so cluster issues need a separate operations owner. Separately, a partner can provide implementation, hardening and ongoing support under its own written scope.
Questions to put to an implementation partner before you sign
Start with location and keys, because every other sovereignty claim depends on them. Ask the partner to list each data store that holds customer conversations, attachments and search indexes (PostgreSQL, the Redis cache used for realtime websockets, Elasticsearch if it is deployed, Memcached in multi-instance setups, and the attachment storage) and to name the physical site, cloud account or data center for each one. Then ask who holds the encryption keys, where backups are written, and whether any backup target or monitoring service sits outside the EU. A partner that answers "the EU region" without naming the store, the account and the key custodian has not answered the question. Ask for a written data flow diagram that a third party can check. Next, test remote support access, since EDPB Guidelines 05/2021 treat remote access from a third country as a transfer even when the support engineer only views data on a screen. Ask who can open a session into the production helpdesk, from which countries, through which bastion or VPN, under what approval, and how each session is recorded. Ask how the partner handles a third-country authority request: who receives it, whether it is assessed against GDPR Article 48, and whether the partner commits to notify you where the law allows. Ask for the written procedure, not a summary of intent.
Then test the operational work. Ask how erasure and access requests are executed across the ticket database, the search index, attachments, the Elasticsearch index if present, and backup sets with a defined retention window, and who signs off each step. Ask how a security release such as Zammad 7.2.2 (8 October 2026) or 6.5.5 (15 October 2026) is tested, staged, rolled out and rolled back, and how long a version can remain unpatched in your environment. Ask how a migration from Zendesk or Freshdesk preserves ticket history, agent and requester identities, timestamps, attachments and merged tickets, and whether the partner uses the built-in migrators or custom API work for anything they do not cover. Ask the partner to show a reconciliation report from a test migration. Finally, demand a fixed written scope with deliverables, dates and acceptance criteria, and ask which evidence the partner will hand over at the end: architecture and data flow documents, access logs, the remote access procedure, the erasure runbook, patch records and migration reconciliation. Confirm what support is included after go-live, what the support plan covers (for Zammad self-hosted subscriptions, the vendor's support is separate from the implementation partner's work), and who is accountable when a fault sits between layers. DeployOpen prepares evidence for assessments but does not issue audit reports, so confirm with your auditor which artifacts they will accept.
How DeployOpen scopes, builds and supports a sovereign helpdesk
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source helpdesk platforms inside your own cloud accounts, data centers or air-gapped networks. For EU data sovereignty work, we start by mapping where every ticket, attachment and log lives and who can reach it, then build and document the platform to match that map.
How we scope
- Map every channel, mailbox and integration that carries customer conversations into the helpdesk and where each one is hosted
- Define which personal data fields, attachments and audit logs need erasure and access request handling, and who approves them
- Agree the written, fixed scope, deliverables and timelines before work starts, with any ongoing support set out as a retainer
How we build
- Deploy the chosen helpdesk platform and its database, cache and search components inside infrastructure the client controls
- Configure SSO, role separation, encrypted attachment storage and mail channels, then test them against the agreed scope
- Document data flows, administrator access paths and any remote support access so the team can check transfers against its own assessment
How we hand over
- Deliver runbooks for backups, restores, upgrades and security release application, with the steps your team will run itself
- Provide the evidence pack for your assessors, including configuration records, access reviews and data location documentation
- Walk administrators through erasure and access request procedures on ticket history so the process works without DeployOpen present
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build
- Apply vendor security releases to the platform on a schedule agreed in the retainer, with changes recorded in the evidence pack
- Run security testing of the helpdesk, its integrations and its APIs when the client requests it, and report findings in writing
