Self-hosted customer email for banks and financial services

A current data flow diagram showing where subscriber lists, email content, consent records and sending logs live, and every system that touches them. Examiners look for the boundary of approved infrastructure, the sending service used for delivery, and any tracking pixel or link redirect that passes data outside it. The diagram should name the component that holds each data set, such as the PostgreSQL database behind listmonk or the MySQL database behind Mautic, and the outbound SMTP or API path. DeployOpen prepares this diagram from the agreed scope and the deployed configuration, but the examiner or auditor decides whether the design is acceptable.

An access review is a dated export of every account, role and API token on the platform, compared against the approved list of people who should hold each one. On listmonk, the relevant evidence covers OIDC single sign-on configuration, granular roles, permissions and API tokens. On Mautic, it covers its user roles and authentication setup. Reviewers should be able to see who approved each grant, when it was last used and when it was removed. Where the Safeguards Rule applies, multi-factor authentication must cover individuals accessing the system unless the Qualified Individual approves an equivalent control in writing. Confirm with your own identity team how these checks are scheduled and who signs them off.

The record should show who created the campaign, who approved it, the version of the template that was approved, the segment used, and the time it was released. In a self-hosted setup, these facts come from the platform's audit trail, the application log for the send, and the version history of templates kept in your own repository or database. Separating regulatory notices from marketing messages helps here, because each stream can carry its own approval path and sign-off. Ask your compliance team which approvers are required for each message type before the first send, and confirm that the platform's logs retain these events long enough for your review cycle.

Examiners look for proof of consent for each list, the method used (single or double opt-in), the timestamp, and the source of the sign-up. They also expect suppression records showing that unsubscribed, bounced and complained addresses are excluded from later sends, and that suppression is applied across every list and campaign. In listmonk, subscriber status, list subscription status and opt-in records are stored in the database, and bounce and campaign analytics are available for review. Confirm with your legal team which consent standard applies to each market, since rules differ by jurisdiction. Keep suppression lists in the same approved infrastructure as the subscriber data so that exports can be produced on request.

Retention evidence has two parts: a documented schedule that states how long sent communications, logs and subscriber records are kept, and restore tests that show the data can be recovered. The restore test should take a database backup from the PostgreSQL or MySQL store, restore it to an isolated environment, and confirm that sent-message history, campaign records and consent data are readable. Record the date, the backup used, who ran the test and the result. DeployOpen can plan, implement and document backup and restore procedures inside your infrastructure and prepare the test records, while your auditors decide whether the retention and recovery design meets your obligations. Confirm the required retention periods with your regulatory and records teams before the schedule is set.

Under DORA, a register of information must list all contractual arrangements for ICT services, and each ICT contract must state where services are provided and data processed, give advance notice of changes, and cover data return on termination or insolvency of the provider. For an email setup, prepare one summary per external sender, relay or hosting provider, covering the processing location, subprocessors, notice of change, data return terms and the documented exit plan. Where the service supports a critical or important function, the exit strategy must be documented and tested. Ask your legal and procurement teams to confirm which of these apply to your entity, since DORA scope depends on the type of financial entity.

Cost splits into one-time build work and recurring operations. The build covers installing the platform, configuring sending domains and authentication, setting up single sign-on, integrating with customer and consent data, building approval workflows, and documenting controls for assessors. Recurring costs cover hosting, database and backup operation, patching and upgrades, monitoring, the sending service you pay for, and the staff time to run approvals and handle bounces and complaints. The biggest drivers are the number of integrations with core banking or CRM systems, how many distinct message types need approval paths, the size of the subscriber base, and how much evidence your compliance team needs. Ask any provider for a quote that lists these lines separately, names who is paid for each, and states which items recur and on what basis. DeployOpen does not publish a price list, and a quote follows from the written scope.

The duration depends mainly on the scope agreed in writing, the state of your identity and data environment, and how many internal approvals your change process requires. In general terms, the longest phases are rarely the software installation. They are usually the data mapping, the agreement on which messages count as regulatory notices, the design of approval and retention rules, and the security and risk review of the sending service. Institutions with clean customer identifiers, existing consent records and an established change board tend to move faster than those that must reconcile several legacy lists first. Ask a partner to show the phases, the dependencies on your teams and the review points in the statement of work. No specific durations are assumed here, so confirm them against your own environment and governance calendar.

Your team owns the decisions and access that no partner can make for you. You will need to name a business owner for each message category, approve the classification of regulatory notices versus marketing, and provide access to identity, DNS, certificate and sending-domain administration. Security and compliance staff should supply the control requirements, the third-party risk file for the sending service, and the retention schedule that applies to customer communications. Data owners must confirm which subscriber fields are personal data, which consent sources are valid, and where the data may be stored. Finally, operations staff must agree on on-call coverage and who approves sends. Missing any of these usually lengthens the project more than any technical issue.

A capable platform team can install and operate a platform such as listmonk, Mautic or Dittofeed without outside help, and many do. The harder question is whether your team can also deliver the regulated parts: approval workflows, separation of notice and marketing streams, retention evidence, exit planning and documentation that an independent assessor will accept. Check whether you have staff who can cover patching windows, incident response for a sending outage, bounce and complaint handling, and the change control your regulator expects. Where those skills or hours are missing, an implementation partner can plan, implement, harden, document and support the platform inside your infrastructure under a fixed-scope agreement, with ongoing support available as a retainer. Your own team should still own the policy decisions.

Regulatory notices, such as account statements, fee changes, security alerts and contract terms, should run on a separate transactional stream with its own sending domain, templates, approval path and suppression logic. Marketing campaigns need consent checks, unsubscribe handling and their own list segmentation. Keeping these streams apart prevents a marketing unsubscribe from blocking a legally required notice, and prevents a campaign approval from being used to send a notice. In the build, list and template permissions should differ by stream, approvals should record who authorized each send, and reports should show delivery separately for each category. Your legal and compliance teams should confirm the classification of every message type before the first send, because the platform will not make that judgment for you.

Retention needs a written schedule for subscriber records, consent evidence, sent message content, delivery logs and approval records, because each may follow different rules. The platform must keep these records in your approved storage, and backups must follow the same schedule. For exit, DORA Article 28(8) requires documented, tested exit strategies and transition plans for ICT services that support critical or important functions, and Article 30(2) requires contracts to address data return on termination. Self-hosting helps because you hold the data, but you still need a documented export path and a tested way to move lists, consent records and templates to another platform. Record the sending service in your register of information and confirm its processing location and data return terms in the contract.

Assessors usually ask for a few concrete artifacts: an access model with single sign-on and multi-factor authentication, role separation between editors and approvers, logging of sends and configuration changes, encrypted connections, a patching and upgrade process, and tested backups. For card-related messages, PCI DSS scope depends on whether the email system stores, processes or transmits cardholder data, so confirm that boundary early. For Swift-connected environments, the Customer Security Controls Framework applies to the Swift infrastructure itself. Ask your compliance team which control IDs and standards apply, then map each platform setting to that evidence. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the reports and attestations.