How open source marketing automation supports GDPR consent in practice
If your marketing team emails or runs campaigns to contacts in the EU, GDPR consent for marketing is a lawful basis decision backed by records you can produce on demand, and a self-hosted Mautic installation can hold and enforce those records inside your own infrastructure. Article 6(1) allows processing only where at least one of six bases applies, including consent, performance of a contract and legitimate interests. Choosing consent for a newsletter is therefore a deliberate decision, not a default. Under Article 7(1), where processing is based on consent, the controller must be able to demonstrate that the data subject consented, which turns the question into one of evidence: who consented, when, to what wording, through which form and with what information shown at that moment.
The GDPR requires no audit, attestation or certificate, so there is no single document that proves compliance. Certification under Article 42 is voluntary and does not reduce your responsibility. What you need is a set of controls and records that an independent auditor or supervisory authority can test. DeployOpen prepares those systems, controls and evidence in your environment, including consent capture configuration, record retention and withdrawal handling, but it does not issue audit reports or attestations. Before you commit to a design, confirm with your legal counsel which basis applies to each campaign type, and confirm with the EDPB Guidelines 05/2020 on consent which records they expect you to keep, since those guidelines suggest recording how and when consent was obtained, the information presented at the time and the consent workflow.
Which GDPR consent requirements Mautic must be configured to meet
This table maps each GDPR consent and objection requirement to what the controller must be able to show and how to configure Mautic to meet it. Read each row as a control to build and a piece of evidence to keep. The main takeaway is that Mautic does not decide lawful basis for you, so the configuration must record consent and honor withdrawal and objection across every send path.
| Requirement | What the controller must do | How to configure Mautic and the evidence to keep |
|---|---|---|
| Article 6(1), lawful basis | Name one lawful basis per processing purpose, such as consent for newsletters or legitimate interests for certain B2B outreach, and document it before sending | Record the basis per campaign or list in your processing register. Mautic does not set the basis, so keep the decision outside the tool and link it to segment names |
| Article 7(1), demonstrating consent | Be able to show that each data subject consented to the specific processing | Add contact fields for consent source, consent timestamp and the consent wording version. Keep form submissions and the page content as shown at the time |
| EDPB Guidelines 05/2020, consent records | Keep a record of how and when consent was obtained, the information presented and the workflow, not just a statement that the website is configured correctly | Store the opt-in form version, the double opt-in confirmation event and the IP or source channel in contact history. Export these records for assessors |
| Article 7(3), withdrawal as easy as consent | Allow withdrawal at any time, tell the person this before consent is given, and make withdrawal no harder than giving consent | Provide a one-click unsubscribe and a preference centre on each email. State the withdrawal right in the form text. Test that unsubscribe works from a mobile client |
| Article 21(2) and (3), objection to direct marketing | Stop direct marketing processing on objection, at any time, and stop using the data for that purpose | Set a do-not-contact flag that blocks all marketing sends, including manual and API-triggered ones. Confirm that suppressed contacts are excluded from segments and campaigns |
| Article 21(4), disclosure at first communication | Bring the right to object to the person's attention clearly, separately from other information, no later than the first marketing message | Place a separate objection notice in the first campaign or welcome email, with a visible opt-out link. Keep a copy of the template for each version sent |
| Suppression across channels | Honor objections and withdrawals in every channel the organization uses for marketing | Sync suppression to the CRM and any sending service. Confirm whether imports, forms and API calls can re-subscribe a suppressed contact, and block that path |
| Campaign-level opt-out and segment exclusions | Exclude people who have withdrawn or objected from each marketing purpose, not only from one mailing list | Build exclusion segments for opt-outs and use them on every campaign. Review campaign logic after each change, since cron-driven segment updates can lag behind manual changes |
Which self-hosted platforms fit GDPR consent for marketing
Consent for marketing needs more than a checkbox. It needs a send engine that records when and how consent was given, honors withdrawal and objection across every channel, and keeps suppression lists in step with campaigns. The options below differ in whether they can run that send and suppression workflow themselves or only collect the consent signal.
Mautic as the primary fit
Mautic is open source marketing automation licensed under GPL-3.0, so the send engine, contact records and campaign logic can run in infrastructure you control. Version 7.2.1 was published on September 23, 2026, and 7.3 is planned as the long-term support release with security support through December 31, 2027. Mautic 7.0 requires PHP 8.2 to 8.5 and MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. The project advises against shared hosting, so plan a VPS or dedicated server from the start. Confirm the version your LTS plan covers before you build on it.
Mautic hosting and runtime requirements
Consent records are only as reliable as the platform that stores them. Mautic needs a supported PHP version, a MySQL or MariaDB database, and a web server such as Apache, Nginx or IIS. Segment updates, campaign triggers and broadcasts depend on scheduled cron jobs, and queued email needs a messenger consumer running. Ask your partner how these services are monitored, because a stalled cron job can keep suppressed contacts in active campaigns. Confirm each requirement against the version you select.
Headless CMS and form tools
Headless CMS platforms such as Strapi, Payload and Directus can capture a consent checkbox and store the submission, and form tools can do the same. None of them is a send and suppression engine. They typically do not manage campaign sequences, unsubscribe handling across mailing lists, or bounce and complaint feedback from the sending service. Use them as capture points that pass consent events into Mautic, and document which system is the authoritative record for each contact's marketing status.
Cost profile without a paid edition
Mautic has no paid edition of the software, so the license is not the cost driver. Recurring costs are the servers, the email sending service, database and backup storage, and administrator time for upgrades and cron monitoring. One-time costs include setup, CRM integration, consent workflow design and any contact migration. Ask a partner to separate these in a quote, and to state who is responsible for patch and LTS upgrades after go-live.
Consent evidence and withdrawal handling
The controller must be able to demonstrate consent, so the consent record, the wording shown and the withdrawal path all need to live in the same system of record that drives sending. Decide how a withdrawal recorded in a form tool or CMS reaches Mautic, how long it takes to propagate, and whether suppression survives contact merges and imports. Test these flows end to end before launch rather than relying on the configuration alone.
How the lawful basis changes the consent workflow
Where the controller relies on consent under Article 6(1)(a), the contact must actively opt in before marketing starts, and the controller must be able to demonstrate that consent was given (Article 7(1)). Withdrawal must be as easy as giving consent, and the contact must be told about that right before consenting (Article 7(3)). In Mautic, this means the opt-in step, the consent statement shown at the time, and the withdrawal path are designed around that basis, not left to default form settings.
- Opt-in evidence: Keep a record of the consent statement, when and how consent was obtained, the information shown at the time and the workflow used, as the EDPB Guidelines 05/2020 on consent suggest.
- Withdrawal path: Provide an unsubscribe or preference link that takes effect without a support ticket or extra steps.
- Pre-consent notice: Show the withdrawal right before the contact agrees, in plain language.
- Granularity: Separate consent for each distinct purpose, such as newsletters and partner offers.
- Consent refresh: Decide with counsel whether older consents remain valid when the wording or purpose changed.
Confirm with your data protection lead which consent wording, retention period and evidence fields your organization requires before the first campaign is built.
Where the controller relies on legitimate interests under Article 6(1)(f), the basis itself does not require opt-in, but the data subject may object at any time (Article 21(1)). For direct marketing, an objection must be honored, and the data must then no longer be processed for that purpose (Article 21(2) and (3)). The controller has to document its balancing test, and the right to object must be brought to the contact's attention clearly and separately at the latest at the first communication (Article 21(4)).
- Balancing test record: Write down the interest, the necessity of processing and how the contact's reasonable expectations and rights were weighed.
- Objection mechanism: Build a one-click objection that stops all direct marketing for that contact and is recorded in the suppression data.
- First-contact notice: Present the right to object separately from other terms in the first email or on the first form.
- Suppression across tools: Make sure an objection in Mautic also reaches any connected CRM or sending service.
- Profiling scope: Check whether scoring or segmentation counts as profiling, since objections cover profiling as well.
Confirm with your legal team whether this basis is available for each campaign type, because Mautic will run whatever basis you record without checking its validity.
For people who already buy from or work with the organization, the lawful basis may be performance of a contract under Article 6(1)(b), or legitimate interests under Article 6(1)(f), depending on the relationship and the messages sent. Contract-based processing can support service messages, while promotional email to customers usually still needs a documented basis and an objection path. Where the basis is consent, portability under Article 20(1) applies to the data processed by automated means, but where the basis is legitimate interests, portability does not apply.
- Service versus marketing: Keep order, renewal and account notices separate from promotional sequences in Mautic campaigns and segments.
- Basis per segment: Tag each customer segment with the basis relied on, so sends can be filtered by it.
- Portability scope: Export contact data for portability requests only where consent or contract is the basis.
- Source tracking: Record where each contact came from, such as a purchase, a sign-up or an import, to support later evidence requests.
- Imported lists: Do not assume customer lists exported from a CRM carry a valid basis for marketing.
Confirm with counsel which customer messages count as contract administration and which count as marketing before you map Mautic segments to lawful bases.
The lawful basis is the controller's decision, made for each processing purpose before data is collected or used (Article 6(1)). Mautic is software and does not choose a basis, check whether one is valid, or warn when a campaign conflicts with the basis recorded elsewhere. The configuration you build determines what the tool does, so the decision must be written down and then reflected in forms, segments and suppression rules.
- Documented decision: Keep a register that maps each marketing purpose to its basis, owner and review date.
- Configuration mapping: Translate that register into Mautic contact fields, form consent fields and segment rules.
- Change control: Route any change to a basis through the same approval as a campaign change.
- Accountability: The controller must demonstrate compliance, so keep the register and configuration exports together.
- Certification is not a substitute: Under Article 42, certification is voluntary and does not reduce the controller's responsibility.
Ask your legal and data protection leads to sign off the register before any Mautic campaign launches, and confirm who owns future changes.
How Mautic records consent, honors withdrawal and stops direct marketing
The consent trail starts at the point of capture, so the first thing to map is how a form or landing page writes to the contact record in Mautic. Each form submission can carry a consent checkbox tied to a specific statement, and the record you need an auditor or data protection lead to see is the stored consent statement with its timestamp, the source (form, page or import), and the wording the person saw. Under Article 7(1), the controller must be able to demonstrate consent, and the EDPB's Guidelines 05/2020 on consent say that pointing to a correctly configured website is not enough, so the evidence has to be kept in the system. Your job before go-live is to walk one test submission through the form, the contact record and the activity log, and confirm that the statement text, time and source are all retrievable. Confirm the exact field and channel behavior for your installed version, since form consent handling and the consent history view have changed between releases.
Withdrawal works only if it is as easy as giving consent, which Article 7(3) requires, so the preference center and unsubscribe link must be reachable from every marketing email and must take effect without a call or manual request. Within Mautic, a contact who opts out of a channel is marked as do-not-contact for that channel, and that status is what your campaigns and broadcasts check before sending. The scheduled parts matter here: segment updates, campaign updates and campaign triggers run on cron jobs, which the Mautic cron jobs documentation says should be staggered, so a withdrawal made today may not remove a contact from a scheduled send until the next relevant job has run. Queued email also depends on a messenger consumer, so a message already sitting in the queue when a contact withdraws needs a test to confirm whether it is suppressed at send time. Check both behaviors on your version and document the timing you actually observe.
Direct marketing objections under Article 21(2) and (3) require that processing for that purpose stops, so suppression must cover campaigns, segments used for broadcasts, and any import or sync that could re-add the contact to a list. The right to object must also be stated clearly and separately at the first communication, under Article 21(4), so the wording belongs in the first email template and the preference page, not only in the privacy notice. Decide who owns a manual objection received by letter or phone, how it is entered as a do-not-contact status, and how that change is checked against the next scheduled campaign run. Ask your implementation partner to set up a test contact, withdraw consent, and show the suppression in campaign and broadcast results, with the cron schedule and queue worker logs as evidence.
Evidence auditors and supervisory authorities ask for on consent
This table maps each piece of consent evidence to the Mautic component or process that is expected to produce it. Read it as a starting inventory: the GDPR requires no audit or certificate, and every item must be confirmed against your own configuration, logs and contracts. Article 42 certification is voluntary and does not reduce your responsibility for compliance.
| Evidence item | Mautic component or process | What to confirm in your environment |
|---|---|---|
| Consent statement versions and information shown | Form and landing page versions, plus a dated archive of the consent wording and privacy notice | Mautic keeps current form content; confirm you archive prior versions outside the platform before each change |
| Timestamped consent per contact | Contact timeline and form submission records with date, time and source | Confirm each opt-in event stores a timestamp, the form or page used and the consent wording reference |
| Withdrawal logs | Contact timeline entries for unsubscribe and preference changes, plus the do-not-contact flag | Confirm withdrawals are logged with date and channel, and that withdrawal is as easy as opting in |
| Objection and suppression records | Do-not-contact status and suppression handling for direct marketing objections | Confirm objections are honored across segments, campaigns and broadcasts, and that suppressed contacts stay excluded after imports |
| Lawful basis register | Not a Mautic feature; maintained as a controller document linked to segments and campaigns | Confirm each segment and campaign records its lawful basis and the data subject rights that apply |
| Legitimate interest assessments | Not produced by Mautic; kept as a documented assessment referenced from campaign records | Confirm an assessment exists for each legitimate interest use and is reviewed when the campaign changes |
| Processor agreements with hosting and sending providers | Contracts held outside Mautic, covering the servers and any SMTP or email sending service | Confirm agreements with your hosting provider and sending service exist, and where data is stored and transferred |
| Access and security controls | Admin user roles, authentication settings, server logs and backup procedures | Confirm named admin accounts, role limits, log retention and tested restores are documented and reviewed |
What Mautic alone does not satisfy under GDPR
Mautic can record consent, honor withdrawal and stop direct marketing on objection, but those features only cover part of the GDPR. The cards below cover the decisions, documents and checks that remain with the controller, whatever software sends the email.
Choosing the lawful basis
Mautic does not decide why you may process a contact. Article 6(1) lists six bases, and the choice controls which rights apply: consent triggers withdrawal and portability, while legitimate interests trigger the right to object under Article 21(1). Document the basis per purpose before building segments, because a contact imported for a newsletter may not be eligible for a sales sequence. Confirm the choice with counsel for each campaign type.
Privacy notices under Articles 13 and 14
Each form, landing page and import path needs a privacy notice that states the controller, purposes, bases, recipients, retention and rights. Articles 13 and 14 set the content, and Article 21(4) requires the right to object to be shown clearly and separately at the first communication. Mautic can host the text, but someone must write it, version it and link it from every capture point. Ask counsel to review the notice for each brand and language.
Legitimate interest assessments
If you rely on legitimate interests for any marketing, the balancing test must be written down before processing starts. Record the purpose, the necessity of the processing, the reasonable expectations of contacts and the safeguards, such as suppression lists and easy opt-outs. The EDPB's Guidelines 1/2024 on legitimate interest add detail on the test. Without a written assessment, you cannot show the balance was struck, and the assessment should be reviewed when the campaign changes.
Retention periods and erasure
Mautic stores contacts, activity and form submissions until someone deletes them, so the retention rules are yours to set. Define how long inactive contacts, unsubscribed addresses, suppression records and campaign logs are kept, and what is deleted on an erasure request. Suppression records usually must survive deletion so that a contact is not mailed again, so document that exception. Check the purge and backup routines against the schedule.
Transfers when data leaves the EEA
Self-hosting keeps data in your chosen location, but sending services, CRM sync, analytics scripts and backup providers may move personal data to third countries. Chapter V (Articles 44 to 50) requires a valid transfer mechanism for each such flow. Map every subprocessor and its location, and confirm whether the EU-US Data Privacy Framework applies to any US recipient through its adequacy decision. Ask each vendor where data is stored and where support staff access it.
Processor terms and breach notification
Hosting partners, email providers and implementation firms act as processors, so each needs a contract under Article 28 covering instructions, confidentiality, subprocessors and deletion. Articles 33 and 34 require notifying the supervisory authority within 72 hours of becoming aware of a personal data breach, and affected individuals when the risk is high. Agree the incident contacts and log access in writing before go-live, and test the runbook once.
Staff training and regulatory change
Marketers who build segments, import lists or write campaigns make consent decisions daily, so train them on the lawful basis, suppression rules and the difference between a withdrawal and an objection. Record completion. The GDPR text was unchanged as of October 2026, but the Omnibus IV proposal (2025/0130(COD)) and the Digital Omnibus proposal (2025/0360(COD)) are pending. Assign an owner to track these changes and confirm any impact with counsel.
Questions buyers ask before hiring help for GDPR consent in Mautic
What drives the cost of setting up GDPR consent in a self-hosted Mautic?
The cost is driven by how much consent work the scope contains, not by a license fee, because Mautic has no paid edition of the software itself. The main drivers are the number of contacts and consent sources (web forms, imports, events, partner lists), how many CRM or CMS integrations must carry consent status, and whether legacy consent records must be migrated and checked. Each adds configuration, testing and documentation. Ask any quote to itemize these components separately: infrastructure, setup of consent fields and forms, integration work, migration of consent evidence, and documentation. Separate the one-time build from recurring hosting, cron and administration, and ask which items recur after go-live.
What does our team need to provide before consent work can start?
Your legal and privacy owners must provide the decisions that the technical work depends on. These include the lawful basis for each processing purpose, the wording of consent statements and privacy notices, and the rules for which withdrawal and objection requests must be honored. You also need a data map showing where contacts enter Mautic, which systems receive them, and which teams can change them. Under Article 7(1) of the GDPR, the controller must be able to demonstrate consent, so someone inside your organization must own the consent policy. Confirm these inputs and their owners in writing before the scope is agreed.
Can our internal team set up GDPR consent in Mautic alone?
A capable internal team can run a self-hosted Mautic, but GDPR consent work needs skills in three areas at once: legal interpretation, marketing operations and platform engineering. Your team should be able to host Mautic on a VPS or dedicated server, since the project advises against shared hosting, and to maintain the cron jobs for segment updates, campaign triggers and broadcasts. The harder question is whether you can prove consent and objection handling end to end. The EDPB Guidelines 05/2020 on consent (version 1.1) suggest keeping records of how and when consent was given and the information shown at that time. If that evidence trail is new to your team, a partner can build it alongside your staff.
How long does GDPR consent setup take in Mautic?
The duration depends on scope, and no fixed timeline applies to every organization. The main variables are the number of consent sources, the amount of legacy consent data to reconcile, the number of integrations, and how many legal reviews are needed before go-live. Because most DeployOpen engagements are fixed-scope, the timeline should be written into the agreed scope with its dependencies, such as when legal approves wording and when the client provides access to source systems. Ask any partner to show which milestones depend on your team and which depend on their own work, and to state what happens if a dependency slips.
How do we keep Mautic upgraded while meeting consent requirements?
Plan upgrades against Mautic's published support dates, because consent logic must keep running on a supported release. Mautic 7.2 receives active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Mautic 6.0 received security support until 30 September 2026, and Mautic 5.2 until 30 June 2026. Mautic 7.0 requires PHP 8.2 to 8.5 and MySQL 5.7 or higher or MariaDB 10.2 or higher. Ask the partner how each upgrade is tested against consent fields, forms, suppression lists and integrations before production, and who owns the rollback plan.
What do the GDPR fine levels mean for this decision?
Article 83 of the GDPR sets maximum administrative fines, not typical or expected amounts. For infringements such as those covered by Articles 25 to 39, the maximum is EUR 10 million or 2% of total worldwide annual turnover. For infringements of the principles, lawful basis, data subject rights and transfer rules, the maximum is EUR 20 million or 4% of turnover. In each case the higher figure applies. The practical point for buyers is that weak consent records and unhandled objections fall under the higher tier. Ask any partner how they will document consent, withdrawal and objection handling so you can show regulators what your system did. A partner prepares evidence and controls, but independent auditors and certification bodies, not DeployOpen, issue any assessment outcome.
Does GDPR consent in Mautic need an audit or certificate?
The GDPR does not require an audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's responsibility for compliance. What the regulation does require is that you can demonstrate consent and honor objections. For a self-hosted Mautic, that means documented consent statements, workflow records, withdrawal paths that are as easy as giving consent, and a clear objection notice given at the first communication under Article 21(4). Ask a partner which of these evidence items they will prepare and which must come from your legal team or an independent assessor.
How a consent configuration moves from scope to evidence
The sequence turns a consent question into a configured, tested Mautic environment and a dated evidence pack that shows how each consent was captured, honored and reviewed. Each step has a written output, so the client can see what was decided, who decided it and what was tested.
Confirm lawful basis for each purpose
Before any configuration, the client's counsel or data protection lead records the lawful basis for each processing purpose, such as marketing emails, profiling for segments, and tracking on web pages. Consent is one of six bases under Article 6(1), and the basis decides which rights apply: the right to object covers legitimate interests and public task processing, while withdrawal of consent covers processing that relies on consent. DeployOpen does not give legal advice. The step is done when a signed purpose register exists and every purpose names its basis, so the configuration can be built against it.
Map data sources and existing consent records
DeployOpen inventories every place contacts enter or already exist: web forms, trade show lists, CRM exports, imports from older tools and purchased lists. For each source, the client documents what was shown to people at the time, how consent was given and whether any record of that proof survives. Where proof is missing, the affected contacts are flagged for re-permissioning or exclusion rather than migrated as consented. The output is a source-by-source map that tells the team which contacts can carry a consent status into Mautic.
Install and harden Mautic on a VPS
DeployOpen installs Mautic on a VPS or dedicated server inside the client's own cloud account or data center, since the project advises against shared hosting. The work covers the supported PHP and database versions, web server configuration, TLS, access restriction for the administrative interface, and scheduled jobs for segment updates, campaign triggers and broadcasts, staggered as the documentation describes. The step is complete when a hardening checklist is signed off and the environment is recorded in the configuration baseline.
Configure consent fields, preferences and suppression
DeployOpen configures the fields that store consent status, the date and source of each change, and the wording version shown to the person. It sets up a preference centre so people can change channels or topics, and a suppression list that blocks sends to anyone who objected or withdrew. Each mailing path is checked so suppressed contacts cannot receive campaign or broadcast email. The output is a configuration record listing every field, form and suppression rule with its owner.
Test withdrawal and objection end to end
DeployOpen runs scripted test contacts through each route: withdrawing consent from an email link, changing preferences, objecting to direct marketing and submitting a suppression request by the channels the client publishes. For each test, the team confirms the contact is suppressed in Mautic, excluded from the next segment and campaign run, and that the change is logged with a timestamp. Failures are fixed and retested. The step closes with a test log attached to the evidence pack, showing the date, the tester and the result for each route.
Produce the evidence pack
DeployOpen compiles the evidence pack that the client's compliance team, internal auditors or an independent assessor can review. It contains the purpose register, the source map, the configuration baseline, the form and consent wording history, the test log, the suppression rule set and the procedure for responding to requests. EDPB Guidelines 05/2020 suggest keeping records of how and when consent was obtained and the information shown at that time, and a statement that the website is configured correctly is not enough. The pack is a set of records to be assessed, not an audit report or certification.
Set a recurring review
The client assigns an owner for consent operations, and DeployOpen agrees with them a review schedule covering wording changes, new sources, Mautic version upgrades and changes to the purpose register. Each review re-runs the withdrawal tests and updates the evidence pack. Upgrade planning follows the Mautic release line, so the client knows which versions still receive security support. This can be delivered as a retainer after the fixed-scope build. The step is done when the review calendar, owner and change log are filed with the evidence pack.
How DeployOpen scopes and delivers GDPR consent controls for Mautic
DeployOpen plans, implements, hardens, documents and supports self-hosted Mautic inside your own infrastructure, so consent capture, withdrawal and objection handling run where your data lives. Engagements start with a written scope that ties each consent control to the GDPR obligation it supports.
How we scope
- Map every contact source, form and import to a lawful basis and the consent statement shown at the time of collection.
- Define how consent records, withdrawals and objections to direct marketing are stored, timestamped and reported in Mautic.
- Agree the scope in writing before work starts, with deliverables and timelines fixed per engagement; no price list applies.
How we build
- Configure Mautic forms and contact fields so consent evidence, including the workflow and wording presented, is retained with each contact.
- Set up one-click withdrawal and unsubscribe paths that are as easy to use as the original opt-in, and suppress contacts across all campaigns.
- Schedule and test the cron jobs and queue consumers that enforce segment, campaign and send suppression, so objections take effect.
How we hand over
- Test consent flows end to end, including objection after first contact, and document the results for your compliance team.
- Deliver written runbooks covering consent record exports, data subject request handling and the controls you should expect to evidence.
- Document what DeployOpen prepared and what remains your responsibility as controller, since readiness is not an audit or certification.
How we support
- Plan Mautic upgrades against the published support windows so consent controls stay on a supported release.
- Retest consent, suppression and withdrawal paths after each upgrade, plugin change or new integration with your CRM.
- Offer ongoing support and continuous testing as a retainer, priced separately from the initial fixed-scope work.
