Why a financial services helpdesk needs more than a shared inbox
A regulated firm that handles complaints, account queries and disputes across email, web forms and phone needs a helpdesk that keeps records it can later produce, not just a place where messages pile up. For most full helpdesk deployments, a self-hosted Zammad is the usual starting point, because it covers ticket history, roles, SLA handling and third-party login in one platform. FreeScout or osTicket can suit narrower teams with simpler routing, but the choice turns on three questions: how long customer communications must be retained, how identity is verified before an account change is made, and what audit trail a regulator or internal auditor can be shown. Answer those first, then pick the platform. Zammad is licensed under AGPL-3.0, which allows self-hosting and modification, and it is the platform in scope for most of this page.
Deploying Zammad in your own infrastructure moves the design work onto your side of the fence. Retention rules, role separation between complaint handlers and account-change staff, and the logging that shows who viewed or changed a ticket all have to be configured and tested, and the data stays in your database and storage. DeployOpen plans, implements and hardens the platform inside your cloud account, data center or air-gapped network, integrates it with your identity provider and telephony, and prepares the configuration and operating evidence that your compliance team and auditors will ask for. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent assessors, so the first step is to ask your assessor which evidence they expect and agree that list before build work starts.
Before you commit to a platform, confirm with your compliance and legal teams which records in the helpdesk count as regulated communications, how long each category must be kept, and whether your current tool can export them in a usable form. Ask a partner to show how Zammad's database, attachment storage and backups would meet those rules, and how a change to a retention setting would be recorded. A shared inbox cannot answer those questions reliably, which is why the decision belongs before the tool is chosen rather than after the first audit request arrives.
Which financial services rules shape the helpdesk build
This table maps the rules most likely to affect a financial services helpdesk to the settings they touch: ticket retention, attachments, sign-in and roles, and vendor records. Read each row as a question to answer with your compliance, legal and security teams before the build is fixed. Rules that do not apply to your entity type may be out of scope, so confirm applicability first.
| Rule or framework | What it asks for | Helpdesk design impact |
|---|---|---|
| Retention of communications (SEC Rule 17a-4(b)(4)) | Broker-dealers must preserve originals of communications received and copies of communications sent relating to the business for at least three years. | Set ticket and email retention so inbound originals and outbound copies persist for the full period, and confirm with counsel whether internal notes and inter-team messages are in scope. |
| Audit controls on systems holding sensitive data (HIPAA 164.312(b)) | Outside finance, but a useful pattern: record and examine activity in systems that hold sensitive data. | Enable and export audit logs for ticket views, edits, merges, deletions and role changes, and confirm which of these your regulator expects to see. |
| MFA for system access (FTC Safeguards Rule, 16 CFR 314.4(c)(5)) | Multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. | Enforce MFA at the identity provider for agents and admins, and keep any written exception for a service account or legacy path on file. |
| Cardholder data scope (PCI DSS v4.0.1) | Applies to entities that store, process or transmit cardholder data, or that could affect the security of the cardholder data environment. | If card numbers or disputes reach tickets or attachments, the helpdesk may fall in scope, so mask or block card data at intake and confirm scope with your QSA or acquirer. |
| ICT contract register and exit strategy (DORA Articles 28(3) and 28(8)) | A register of all ICT contracts, plus documented and tested exit strategies for services supporting critical or important functions. | Record the helpdesk platform, hosting, support subscription and migration providers in the register, and keep a tested plan to export tickets and attachments in a usable format. |
| Contract terms on data location and return (DORA Article 30(2)) | ICT contracts must state where services are provided and data processed, give notice of changes, and cover data return on termination or insolvency. | Ask every hosting and support provider for written data location, sub-processor notice and data return terms, and map them to where ticket data and backups sit. |
| IT general controls on access to programs and data (SEC Release 33-8810) | Example ITGC areas include program changes, computer operations and access to programs and data, relevant to ICFR assessments under SOX Section 404. | Document who can change helpdesk configuration, automations and integrations, approve those changes, and review admin access on a regular cycle. |
What data a financial helpdesk holds and where it must live
Complaint and dispute tickets are the core record of how a firm handled a customer grievance, including dates, root cause, decisions and responses. Regulators and internal reviewers will ask for these records in full, so retention must be set by the firm's own record schedule and the rules that apply to its licence and jurisdiction, not by the helpdesk's default settings. Access should follow the complaint process: frontline agents see their assigned tickets, while complaint handling leads and compliance staff see the wider queue.
- Retention period: Confirm the minimum period for complaint files in your jurisdiction and set it per ticket group, not globally.
- Read access: Restrict the complaints queue to named teams and log who opens closed complaints.
- Immutability of history: Confirm that edits to closed tickets are recorded as changes rather than overwrites.
- Storage location: Keep these records on the firm's own PostgreSQL database inside its controlled environment, with backups held under the same rules.
- Search index: Elasticsearch copies of complaint text inherit the same access and retention rules as the database.
Before go-live, ask your compliance lead to sign off the retention schedule and the access matrix for this class.
Identity data used to verify a caller or correspondent, such as name, date of birth, account number, security questions and verification outcomes, is high-risk because it is the material an attacker would use to take over an account. The helpdesk should record that verification happened and what method passed, rather than storing the underlying secrets. Access should be the smallest set of agents who perform verification, and every change to contact details or authentication factors should be attributable to a named user.
- Minimal capture: Store the verification result and method, not full identifiers or answers to security questions.
- Restricted visibility: Mask identifiers in the agent interface for everyone except verification staff.
- Change trail: Log every change to a customer's email, phone or linked account with the agent and time.
- Storage location: Keep the data in the firm's own database, with no copies sent to external SaaS add-ons.
- Retention: Align the period with your fraud and anti-money laundering record rules, which may differ from complaint retention.
Ask your fraud team which verification fields they require and confirm that the helpdesk configuration matches the minimal set.
Customers often attach bank statements, identity documents, payslips and letters to tickets. These files are usually the most sensitive content in the helpdesk because they are whole documents, not single fields. Attachments are stored outside the ticket text and can be searched if content indexing is enabled, so their storage and search settings need explicit decisions. Zammad stores attachments in its database and file storage and can index email attachment content through Elasticsearch, which is optional but recommended for search, so the firm must decide whether attachment text should be indexed at all.
- Storage backend: Confirm where attachment files physically live, including backups and replicas.
- Content indexing: Decide whether attachment text is searchable, and restrict that index to the same roles as the files.
- Download control: Limit who can download identity documents and log each download.
- Retention: Delete or redact ID scans once the verification purpose ends, unless a rule requires keeping them.
- Encryption: Confirm encryption at rest for the volumes and object storage holding these files.
Ask your security team to test whether an agent without verification rights can open or search for an ID scan.
Customers sometimes paste card numbers, expiry dates or card security codes into messages or attach card statements. Once that data enters a ticket, the helpdesk may fall into the scope of PCI DSS, which applies to entities that store, process or transmit cardholder data or could affect its security. The safer design is to keep card data out of the helpdesk entirely, so the desk is never part of the cardholder data environment. Whether the helpdesk is in scope depends on what it actually receives, so the firm should test that rather than assume it.
- Scope check: Ask your QSA or assessor whether any helpdesk path could receive cardholder data.
- Intake prevention: Add warning text on web forms and email templates asking customers not to send card numbers.
- Redaction: Confirm whether the firm can detect and redact card numbers in incoming messages before agents see them.
- Attachment rules: Block or review card statements before they are stored.
- Current version: Map controls to PCI DSS v4.0.1, the only active version as of the supplied facts, and to the future-dated requirements that took effect on 31 March 2025.
Ask your payments or card team to confirm which control, not the agent, prevents card data from being stored in tickets.
Internal notes are visible to staff but not to customers, and they often contain the most candid content: assessments of risk, speculation about fraud and comments on staff conduct. Because agents write them quickly, they are easy to overlook in access reviews. Notes can also carry customer data copied from other systems. The design goal is to keep notes useful for the case while limiting who reads them and how long they live, with a clear rule for when sensitive comments belong in a restricted case file instead.
- Note visibility: Separate internal notes from customer-visible replies and check that email templates do not expose them.
- Sensitive commentary: Route fraud and conduct matters to a restricted queue.
- Retention: Apply the same schedule as the parent ticket, unless a policy requires shorter life.
- Export controls: Confirm that reports and exports include or exclude notes according to the role.
- Storage: Keep notes in the same self-hosted database so they fall under the same backups and access logs.
Ask your compliance team to review a sample of closed tickets and confirm that notes contain only what the retention rule allows.
Which open-source helpdesk fits which financial team
Financial services support teams differ in size, regulatory exposure and how tightly the desk must connect to IT service management. The cards below set out where each open-source helpdesk fits, where it falls short and what to confirm with the vendor before committing, especially for audit reporting depth.
Zammad for multi-team complaint handling
Zammad fits banks and insurers that run complaint handling across several queues, such as payments, lending and fraud, each with its own agents and escalation rules. Its role model keeps agents within their own teams, and SAML or OpenID Connect login lets the desk use the institution's existing identity provider. Migrator support for Zendesk and Freshdesk helps teams leaving a US-hosted tool. Check that complaint timestamps, reopen history and escalation records meet your regulator's reporting expectations, and confirm audit reporting depth with the vendor before you rely on it.
FreeScout for a small shared inbox
FreeScout suits a fintech or small lender whose support team is a handful of agents working one shared inbox for customer email. Its footprint is lighter than Zammad, which lowers the operating burden for a small team. It is a weaker fit where complaint records need multi-level roles, strict segregation between queues or detailed audit exports, because those needs grow beyond a shared inbox. Confirm how it logs changes to ticket content and who can view or delete customer messages before you use it for regulated correspondence.
osTicket for lighter ticketing
osTicket covers basic ticket intake and assignment for a small operation, such as a credit union branch network or an internal finance helpdesk with simple routing. Its GPL-2.0 licence and modest scope make it easy to run on a single server. It is a weaker fit for teams that need threaded complaint histories, sophisticated SLAs or integration with identity and telephony systems. Ask the vendor or your partner to confirm how it handles retention, deletion of customer data and access logging before adopting it for any regulated complaint workflow.
GLPI or iTop for linked IT service management
GLPI or iTop becomes relevant only when a financial institution needs the service desk tied directly to IT incidents, change records and a configuration database, for example when a payment outage raises both a customer complaint and an internal change request. Keeping these in one system aids change traceability for ICT controls. It adds complexity that a customer-facing complaint desk does not need, so most teams should keep a separate customer helpdesk and integrate it. Confirm which integration approach your architecture requires.
Zammad paid support tiers
Self-hosted Zammad carries no licence fee, but a regulated institution may want vendor-backed support. Zammad sells 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 its pricing page. Compare these against the internal and partner effort you would otherwise carry. Ask what response times, patch commitments and upgrade help each tier includes in writing, because those terms determine whether a tier fits your change-control process.
Integration points that matter for regulated support
A regulated support desk is only as defensible as the systems around it. Identity, customer records, call and message capture, retention, logging and recovery each hold a piece of the evidence a bank, insurer or fintech must produce. Confirm each connector with the platform and your implementation partner before scope is agreed.
Identity provider and upstream MFA
Agents should sign in through your existing identity provider over SAML or OpenID Connect, so that account lifecycle, role mapping and multi-factor enforcement stay in one place. Zammad documents third-party login through SAML and OpenID Connect, but the attribute mapping for agent roles, group membership and deprovisioning must be designed and tested for your directory. Check whether leavers lose access to the helpdesk the same day they lose directory access, and whether local fallback accounts are disabled.
Core banking or CRM identity lookup
Before an agent changes an address, card status, beneficiary or contact method, the ticket should show that the customer was verified against the system of record. This is an integration you design, not a feature you switch on. Ask the partner which fields are passed to the helpdesk, whether verification results are stored on the ticket, and how the agent cannot bypass the check. Keep the minimum customer data needed in the helpdesk so that the core system remains the source of truth.
Telephony recording and call logs
Complaints and account disputes often start on the phone, so call metadata and recordings must be linked to the ticket that records the outcome. Confirm which telephony platform you run, whether call identifiers and timestamps can be attached to tickets, and where recordings are stored and for how long. Recordings usually belong in a separate retention regime from ticket text, so the link should point to the controlled archive rather than copy the audio into helpdesk attachments.
Email gateway and message archiving
Inbound and outbound customer email must be captured in an archive that meets your retention schedule, separate from the helpdesk's own ticket history. Check how the mail gateway forwards messages to the helpdesk, whether original headers and attachments are preserved, and whether outbound replies are copied to the archive. Retention rules for broker-dealer records and other financial communications should be confirmed with your compliance function, not inferred from a platform default.
SIEM and audit log forwarding
Authentication events, ticket access, role changes and export actions should flow to your SIEM so that investigators can reconstruct who viewed a complaint file and when. Confirm which events the platform logs, whether they can be forwarded in a standard format, and whether logs are protected from edits by the helpdesk administrators. The HIPAA audit control wording is a useful model for this even outside healthcare, because it expects activity in systems holding sensitive data to be recorded and examined.
Backup and restore targets
The helpdesk database, attachment storage and search index must be backed up to a location you control, and restores must be tested against a complete ticket history. Zammad stores its content in PostgreSQL, uses Redis for realtime communication and can use Elasticsearch for search, so each component needs its own backup and recovery procedure. Ask the partner for the restore test results you will receive, the recovery point you can commit to, and how backups are kept separate from the production environment.
How a financial helpdesk rollout runs in phases
The sequence turns a helpdesk migration into a controlled change: retention and identity rules are settled first, the firm's own contract and vendor records are updated, and each queue moves only after its evidence is captured and reviewed.
Scope the queues and map retention and identity rules
Your compliance, operations and security leads agree which queues are in scope (complaints, account changes, disputes, general enquiries) and which regulations apply to each, such as record-keeping rules, the FTC Safeguards Rule if you are a non-bank under FTC jurisdiction, or PCI DSS if card data enters the conversation. DeployOpen maps each requirement to a configuration decision: retention periods, who may view or edit tickets, which channels accept customer data, and which identity checks must pass before an account change is recorded. The step closes with a signed requirements register that names an owner for every rule. Confirm with your regulator or counsel which retention periods apply to your entity, because the researched facts do not set a general period for complaint records.
Update the contract and vendor register
If your firm is in DORA scope, the helpdesk becomes an ICT service that must appear in your register of information on contractual arrangements. Your procurement and third-party risk teams record the hosting location, data processing locations, notice terms for changes, data return on termination or insolvency, and a documented exit strategy with a transition plan. DeployOpen supplies the technical inputs for these entries, such as where each component runs and how data leaves the platform, but the contract terms and the register remain your legal and procurement responsibility. The step is complete when the register entry and contract addendum are approved and filed with the owners who will review them.
Design and harden the architecture in your environment
DeployOpen builds the helpdesk inside your cloud account, data center or private network. The design covers the application server, PostgreSQL, Redis for realtime updates, a reverse proxy with TLS, optional Elasticsearch for search and attachment indexing, and Memcached where several application instances run. Hardening includes single sign-on, role and group permissions, encrypted backups, audit logging of administrative and data access actions, and a patch process for security releases such as the 7.2.2 update. The step closes with an architecture record and a hardening checklist that your security team tests and signs off before any customer data arrives.
Migrate queues, users and attachments
Migration starts with an inventory of the source system: open and closed tickets, customer records, agent accounts, attachments, macros, SLAs and automations. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through its API or custom work. DeployOpen runs test imports, reconciles counts and sample records against the source, and checks that attachments keep their links and metadata. Archived records that must be retained but are no longer active are moved into a defined location with their own access rules. The step is complete when reconciliation reports for each object type are accepted by the business owner.
Test integrations and identity controls
Each channel (email, web form, phone or chat connectors), CRM link and identity provider is tested against written cases. Identity tests confirm that multi-factor authentication applies to every staff login, that an account change cannot be recorded without the agreed verification step, and that customer identity checks are performed in the approved system and logged. Access tests confirm that agents see only their queues, and that privileged roles are reviewed. Test results are logged with pass or fail status and retest notes. The step closes when the test register shows no open high-severity defects and your security owner accepts the remaining exceptions in writing.
Pilot with one complaint queue
A single complaint queue runs live with a limited set of agents, supervisors and a named compliance reviewer. The pilot tests complaint categorisation, escalation paths, acknowledgement and resolution workflows, and how reports are produced for management and regulators. Operators log issues in a shared defect list, and DeployOpen adjusts configuration only through the change process. The pilot closes with a review that compares pilot records with the requirements register, confirms the audit trail captures every status change and attachment, and records go or no-go decisions by the owners of each rule.
Cut over and assemble the evidence pack
Remaining queues move in agreed waves, with a freeze window for the source system, final data synchronization, and a rollback plan that your operations team has rehearsed. Once cutover is complete, DeployOpen assembles an evidence pack: the requirements register, architecture and hardening records, contract and register entries, migration reconciliations, test results, pilot review, change approvals and access reviews. The pack prepares your teams for internal audit, external auditors or supervisory questions. It does not constitute an audit opinion or certification, which independent assessors issue. The step is done when the pack is accepted and the source system is set to read-only or retired on an approved date.
Run the platform and apply security releases
After handover, the platform runs under a documented operating model covering monitoring, backups and restore tests, user and role reviews, and a security release process. Each release is assessed against your change policy, tested in a staging copy, and applied with a recorded approval. Because Zammad published security releases on separate lines, such as 6.5.5 and 7.2.2 in October 2026, the process must track both supported branches your team runs. Ongoing support, upgrades and continuous testing can be provided under a retainer agreed in writing. The step closes with a runbook, an owner for every control, and a review calendar that the compliance team signs.
Evidence regulators and auditors ask for from the helpdesk
This table maps each piece of evidence a bank, insurer or fintech may be asked to produce from its helpdesk to the component or process that generates it. Read each row as a question to answer before an examination: what does the assessor want to see, and which part of the Zammad or FreeScout setup, or which internal process, produces it. DeployOpen prepares this evidence for assessment; it does not issue audit reports or certifications.
| Evidence | Produced by | What to confirm before an assessment |
|---|---|---|
| Retention configuration and proof of preservation | Zammad ticket retention settings, database backups and an archive copy of communications stored outside the live application | Confirm with your compliance lead whether SEC Rule 17a-4(b)(4) applies to your entity, and that originals and sent copies are kept for the required period in write-once or equivalent storage |
| Access reviews and role lists | Zammad roles, groups and agent permissions exported on a schedule, reviewed against HR and joiner-mover-leaver records | Confirm that every queue holding complaint or account-change tickets has a named owner and that reviews are signed and dated |
| MFA enforcement records | Identity provider settings for SAML or OpenID Connect login, plus Zammad authentication configuration showing second factor requirements | Confirm MFA applies to every agent account, including shared or service accounts, or that a written exception is approved under 16 CFR 314.4(c)(5) where the FTC Safeguards Rule applies |
| Ticket and admin audit logs | Zammad activity history on tickets, admin configuration change logs, and forwarded logs from the reverse proxy and database | Confirm logs record who viewed or changed a complaint, identity verification step or account change, and that they are kept in a location agents cannot edit |
| Change records for security releases | Upgrade tickets and change log entries for releases such as Zammad 7.2.2 (October 8, 2026) and 6.5.5 (October 15, 2026) | Confirm the patch cadence you commit to, the test environment used before production, and the rollback plan kept with each change record |
| Backup and restore test results | Scheduled database and attachment backups, with dated restore tests into a separate environment and recorded results | Confirm restore tests cover PostgreSQL data and attachment storage together, and that recovery times are measured against your own tolerance, not a default |
| Register of ICT contracts and exit plan evidence | Contract register entry for the helpdesk stack and any support subscription, plus a documented and tested exit plan for migrating tickets elsewhere | Confirm with legal whether DORA Article 28(3) and 28(8) apply, and that the contract states data location and data return on termination as Article 30(2) expects |
| PCI scope statement if cardholder data appears | Written scope statement, data discovery results and a tickets and attachments review confirming whether card numbers or sensitive authentication data are present | Confirm with your QSA or acquirer whether the helpdesk is in or out of scope under PCI DSS v4.0.1, and that agents are trained not to accept card data in tickets or emails |
Deployment constraints that change the design for banks and insurers
For a bank or insurer in scope of DORA, the deployment model is a contract question before it is a technical one. Article 30(2) requires every ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover return of data on insolvency or termination of the provider. Article 28(3) requires a register of all such contractual arrangements, and Article 28(8) requires documented, tested exit strategies for ICT services that support critical or important functions. A helpdesk that holds complaint files, identity evidence and customer correspondence is very likely to fall into that second group. Self-hosting Zammad, FreeScout or osTicket inside your own cloud account or data center means the database, attachments and search index sit in a location you already name in your register, so the residency clause and the exit plan describe infrastructure you control rather than a multi-tenant service you must monitor from outside.
The same design affects vendor concentration. A SaaS helpdesk adds a new ICT provider, a new sub-processor chain and a new subcontracting question for each change the provider makes. With a self-hosted platform, the open-source license is not a commercial contract with a supplier, so the firm's obligations concentrate on the implementation partner, the hosting provider and the support subscription, if one is bought. Confirm with your third-party risk team which of these count as ICT third-party service providers under your framework and record each one. Ask the implementation partner to document data return and removal from the database, file storage and search index, since an exit plan is only tested if the data can actually be moved out.
Segregation is the second design decision. Customer-facing channels such as a public web form, inbound email or a chat widget should not share a network segment or a database role with internal queues that handle complaints escalated to compliance, fraud cases or identity remediation. A common pattern is to place the web and mail ingress in a demilitarized zone, terminate TLS at a reverse proxy (Zammad supports Nginx or Apache), and keep the PostgreSQL database, Redis and any Elasticsearch cluster reachable only from the application tier. Separate groups, roles and mail connectors for each queue, and review them against your access control matrix. If the helpdesk handles card-related disputes or stores cardholder data, a Payment Card Industry Data Security Standard scope question may apply, and whether the channels, databases or agent workstations fall inside the cardholder data environment must be confirmed with your Qualified Security Assessor. Similarly, if the helpdesk supports Swift-connected operations, confirm with your assessor which Customer Security Controls Framework controls it touches before you finalize the design.
What financial firms ask before a self-hosted helpdesk project
What does a self-hosted Zammad helpdesk cost for a financial firm?
The software itself has no license fee. Zammad is licensed under AGPL-3.0, and self-hosted Zammad carries no license fee, so the spend falls into four components: an optional vendor support subscription, hosting, migration and integration work, and internal staff time. Zammad sells 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. Hosting, databases, search and cache infrastructure, backups, and migration from your current tool recur or arrive as one-time work. Ask any partner for a written scope that separates one-time project work from recurring run costs.
How long does a helpdesk implementation take at a bank or insurer?
The timeline depends on scope, so confirm it in writing before work starts. The main variables are the number of channels (email, web forms, phone links), the volume and format of historical tickets to migrate, the identity integration with your single sign-on provider, and how many approval rounds your compliance team needs for retention and access rules. Zammad supports SAML and OpenID Connect for third-party login, so an identity review early in the project shortens later rework. Most engagements are fixed-scope, so the agreed scope, deliverables and timeline appear in the same written document.
What must our firm supply before a helpdesk partner starts?
Four roles need to be named before the project begins. A requirements owner (usually the head of customer operations) decides which queues, channels and service levels are in scope. An identity administrator controls the single sign-on connection, group mappings and multi-factor enforcement. A data owner decides retention periods and which attachments and personal data may be stored. A compliance reviewer checks complaint handling rules, legal hold needs and the evidence you will keep. Without these roles, decisions stall during testing and the rollout slips.
Can our internal IT team run a self-hosted helpdesk without an outside partner?
Yes, if the team has the skills and the time to operate it. Zammad runs on PostgreSQL 15 or newer, Redis 7 or newer, and a reverse proxy such as Nginx or Apache, and it uses Elasticsearch for search and Memcached for multi-instance deployments. Someone must own patching, backups, restore tests and monitoring, and security releases must be applied promptly (Zammad published security releases in October 2026 for both the 6.5 and 7.x lines). Many firms keep day-to-day administration internal and buy an outside partner for the initial build, integration, hardening and the documented runbook. Decide which of these you will own before choosing a support plan.
Does a helpdesk alone satisfy SEC or FTC recordkeeping and safeguard rules?
No. A helpdesk is one control within a compliance program, not a compliance program on its own. SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications received and copies of communications sent relating to the business for not less than three years, so the helpdesk must be configured to retain and protect those records in a way your broker-dealer obligations allow, and you must confirm with counsel which communications qualify. The FTC Safeguards Rule (16 CFR 314.4(c)(5)) requires multi-factor authentication for any individual accessing any information system unless the Qualified Individual approves an equivalent control in writing. Map each helpdesk function to the rule, then document the evidence and the owner for each one.
Do we need a DORA register of information or exit plan for a helpdesk?
If your firm is a financial entity in scope of DORA, the helpdesk is an ICT service, so it belongs in your register of information on contractual arrangements under Article 28(3). If the helpdesk supports a critical or important function, Article 28(8) also expects a documented, tested exit strategy and transition plan. Article 30(2) requires the contract to state where services are provided and data is processed, and to cover data return on termination. For self-hosted software, the exit plan should cover the data export format, the retention of ticket history and the time needed to move to another tool. Confirm with your regulator and legal team which obligations apply to your entity.
What evidence will auditors and regulators ask the helpdesk to produce?
Expect requests for access logs, change records for configuration and integrations, backup and restore test results, and proof of who could read or change customer complaints. Audit controls matter here: HIPAA's 164.312(b) is not the applicable rule for most financial firms, but the same principle applies, requiring systems to record and allow review of activity. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask any partner which evidence it will hand over and in what format.
Questions to put to an implementation partner
Ask the partner who sets retention for each queue and who approves it. A complaints queue, a general servicing queue and a fraud or dispute queue usually carry different retention periods, and the answer should name the role that signs off each one, such as the compliance officer or records manager, plus where that decision is written down. Ask how Zammad's data retention settings are mapped to the firm's schedule, whether deletions are logged, and whether the partner can show a test deletion run on a copy of the data. Ask also which communications the firm must keep outside the helpdesk (for example, voice recordings), since the helpdesk schedule alone rarely covers the full record. Confirm the applicable retention rule with your regulator and legal team, not with the vendor.
Ask how MFA is enforced for every agent account, including administrators and service accounts, and where any exception is approved. The partner should explain whether MFA is enforced by the identity provider through SAML or OpenID Connect, or by the application itself, and what happens to local accounts that bypass SSO. For any exception, ask for the written approval record that the FTC Safeguards Rule requires where a Qualified Individual accepts an equivalent control (16 CFR 314.4(c)(5)), and ask who keeps that record and how often it is reviewed. Also ask how the partner tests that a disabled identity cannot still reach ticket history or attachments through an API token.
Ask how DORA contract and exit records are produced from the helpdesk deployment itself. Under DORA Article 28(3), the firm needs a register of information on ICT contractual arrangements, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. The partner should show which items they will deliver: where the hosting and data processing takes place, how the firm would export tickets, users, attachments and audit logs if the partner or the platform had to be replaced, and when that export was last tested. Ask for a sample exit runbook and confirm with your DORA lead which contract clauses under Article 30(2) remain your responsibility. Ask also whether attachment storage can be moved to firm-controlled object storage, because that decision changes the exit plan.
How DeployOpen scopes and runs a financial helpdesk
The sequence turns a financial services support requirement into a written, fixed scope, a hardened self-hosted Zammad or comparable helpdesk inside your infrastructure, and compliance evidence your assessors can review.
Confirm the business case and regulatory perimeter
DeployOpen meets your support leadership, compliance lead and information security team to list the channels in use, the complaint and retention obligations, the regulators and contractual frameworks that apply, and which customer data enters the helpdesk. The output is a short requirements register that names each obligation and the owner who will confirm it. Confirm with your own counsel and compliance function which regimes apply to your entity, since the applicable rules differ by licence type, jurisdiction and business line.
Map data flows and current tooling
DeployOpen documents how customer conversations currently arrive and leave, including email, web forms, phone notes, and any existing helpdesk, CRM or telephony links. The team identifies where cardholder data, account identifiers and sensitive authentication data could appear in tickets and attachments, so that these paths can be excluded or controlled. The output is a data flow diagram and a list of systems in scope for any payment-related assessment, which you should confirm with your qualified assessor.
Agree the architecture and hosting location
DeployOpen proposes a reference design for the helpdesk, covering the application, PostgreSQL, Redis, search, reverse proxy, attachment storage, backups and identity integration, all inside your cloud account, data center or air-gapped network. Hosting location, data residency and any vendor access paths are written down, because contracts for ICT services need to state where data is processed and how it is returned. The output is an approved architecture decision record that your security and procurement teams sign off.
Write the fixed-scope proposal
DeployOpen writes a scope document listing deliverables, responsibilities, acceptance criteria, exclusions and a timeline agreed with you before any work starts. A quote follows from that written scope, so the scope should state integrations, migration volume, number of channels, testing deliverables and evidence packs. The output is a signed statement of work. Ask for the quote to separate one-time implementation work from recurring items such as subscriptions, hosting, backups and support.
Harden, integrate and configure identity
DeployOpen implements the helpdesk with hardened settings, connects single sign-on and multi-factor authentication for agents, and configures role separation between complaint, fraud and general queues. Identity checks before account changes are designed as documented workflows with approval steps, not left to agent discretion. The output is a configuration baseline and a test record showing that access, role and approval controls behave as specified.
Run security testing before go-live
DeployOpen runs application, API and infrastructure security testing against the helpdesk and its integrations, then tracks findings to closure with your team. Where the helpdesk is connected to AI features or agents, those are tested separately. The output is a findings report with retest results and a list of accepted residual risks signed by a named owner.
Prepare audit trail and retention evidence
DeployOpen configures logging, retention settings and backup procedures, and documents how they are tested, including restore tests. Evidence packs map each control to the item an auditor or regulator would ask for, such as access logs, change records and retention configuration. DeployOpen prepares this evidence but does not issue audit reports or attestations, which independent assessors provide. The output is a compliance readiness pack and a tested restore record.
Hand over, then support under retainer
DeployOpen delivers runbooks, administrator training, an upgrade and patching procedure, and the handover documentation your operations team needs. Ongoing support, upgrades and continuous testing can be taken as a retainer, scoped in writing. The output is an accepted handover and a support arrangement with defined responsibilities for security patches and vendor releases.
