How Mautic GDPR consent settings support marketing compliance
Mautic provides per-channel Do Not Contact, a preference center, IP anonymization and cookie-based tracking that support GDPR marketing obligations. A marketing lead or privacy officer who must show that email and tracking respect consent and objections needs to know which settings produce that evidence and which decisions remain with the controller. Under Article 7(1), where processing relies on consent, the controller must be able to demonstrate that the data subject consented. Article 7(3) requires that withdrawal be as easy as giving consent, and the data subject must be told this before consenting. Mautic's preference center lets a contact remove one channel, which sets Do Not Contact for that channel only, so the settings you choose determine whether withdrawal actually works in practice.
The platform helps with the mechanics behind Articles 7 and 21 and with parts of Article 32 on security of processing. Under Article 21(2) and (3), a data subject may object to direct marketing at any time, and processing for that purpose must then stop. Article 21(4) requires that this right be brought to the person's attention clearly and separately from other information, at the latest at the first communication. Mautic can carry the wording and enforce the outcome, but your team must write the objection text and test it. For Article 32, the Anonymize IP setting limits how much identifying data is stored, and access controls such as user accounts and optional SAML single sign-on reduce who can change consent records.
Several obligations sit outside the software. Mautic does not decide your lawful basis for each campaign, write your privacy notices, set retention periods for contact and tracking data, or govern transfers to third countries under Chapter V. It also does not run breach response, which Articles 33 and 34 expect you to handle within your own process. Tracking needs particular care: Mautic sets cookies with a lifetime of one year, identifies returning visitors by cookie, and stores a device ID in browser local storage when the tracking script is used. Your cookie notice, consent banner decisions and retention rules must describe exactly that behavior, so confirm the final configuration with your legal counsel before launch.
The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary and does not reduce the controller's responsibility. The stakes are nonetheless material. Article 83 sets maximum fines of EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, for infringements of the principles and data subject rights. Scope the work before configuration starts: name an owner for consent wording, define how withdrawal and objection requests are tested end to end, decide how consent evidence is exported and retained, and document who signs off on each campaign's lawful basis. Ask any implementation partner to show these items in the written scope.
Mautic GDPR consent requirements mapped to platform settings
This table maps six GDPR provisions to the Mautic features that support them and the configuration each one needs in your instance. A Mautic capability supports a requirement but does not satisfy it alone, and the lawful basis and wording of consent requests must be decided by the controller.
| Requirement | Mautic capability | Configuration needed |
|---|---|---|
| Article 7(1): demonstrate consent | Form submissions and contact history, which you must confirm hold the evidence you need | Confirm what each capture form records, then document where consent evidence is kept and for how long |
| Article 7(3): withdrawal as easy as giving consent | Preference center lets contacts remove a channel, setting Do Not Contact for that channel only | Publish the preference center, set which channels and categories contacts can change, and test the path end to end |
| Article 7(3): told before consent | Form and preference center text, which is content you write | Add withdrawal wording to consent forms and the privacy notice before collection, with wording set by the controller |
| Article 21(2) and (3): objection to direct marketing | Per-channel Do Not Contact, pause, frequency limits, and category or segment removal | Check campaigns and broadcasts honor Do Not Contact, and confirm cron jobs run so segment changes take effect |
| Article 21(4): objection brought to attention at first communication | Preference center link that can be placed in outgoing emails | Add a separate, clearly worded objection notice and preference center link to the first email template |
| Article 32: security of processing | Anonymize IP stops storing full IP addresses; tracking cookies last 1 year | Enable Anonymize IP, review tracking cookies and the device ID in local storage, and restrict admin access and backups |
What Mautic tracking stores and how Anonymize IP changes it
The first step is knowing what the tracking layer writes to the visitor's browser. Mautic tracking sets cookies with a lifetime of one year, and it uses them to recognize a returning visitor so later page views can be tied to the same record. When the tracking script is used, Mautic also stores a device ID in the browser's local storage. Local storage is a separate browser store, so a cookie-only review will miss it. Your site inventory should list both mechanisms, the pages where the script loads, and the contact data the identifiers feed.
Anonymize IP is the setting that changes what the server keeps. With it enabled, Mautic stops storing full IP addresses for visitors and for contacts. The Mautic documentation describes the setting as aiding GDPR compliance. Read that as the vendor's stated purpose, not as proof that your configuration is compliant. The setting controls what Mautic stores. It does not decide whether your site needs consent for the cookies, what your privacy notice says, or how long web server logs, backups and exports keep original addresses. Those remain part of your own review.
Consent is a legal question that a platform setting cannot answer. Whether cookies and device identifiers need consent depends on your obligations under ePrivacy rules in each market where you operate, on how your cookie banner is designed, and on whether any tracking is strictly necessary for a service the visitor requested. Ask counsel to decide this per jurisdiction and record the answer alongside the banner configuration. If consent is required, the tracking script should not run before the visitor's choice is recorded, and that record must be retrievable later to show what was chosen and when.
Confirm the exact behavior on the Mautic version you run before you document any of this. The cookie lifetime, the local storage mechanism and the Anonymize IP behavior should be checked against the release line you plan to operate, because settings and defaults can change between releases. Ask your implementation team to test on a staging instance: load a page with the script, inspect cookies and local storage in the browser, submit a form, and then check what the contact record and stored IP fields show. Record the results with the version number so the documentation matches the running system.
Mautic GDPR consent records to keep for an assessment
An assessor will ask how you know a contact agreed, objected or was suppressed, and when. The cards below list the records a configured Mautic can produce, what each one proves and how to export or retain it. Together they support your own assessment, but none of them replaces an independent review.
Contact timeline and channel Do Not Contact history
The contact timeline shows activity, and channel Do Not Contact entries show which channels a contact has opted out of and when. These records show that a marketing message was suppressed after an objection, which addresses Article 21(3). Export the timeline for sample contacts during a review, and confirm in your version whether DNC entries and their dates can be exported in bulk. Retain exports under your retention schedule, since deleting a contact may also remove its history.
Preference center change records
Preference center submissions show when a contact paused messages, reduced frequency, or removed a channel, category or segment membership. These changes demonstrate that withdrawal was as easy as consent, as Article 7(3) requires. Check in your version what history is kept for each preference change, including the old and new values, and whether it is retained when the contact is updated later. Export a sample of changes before any clean-up job runs.
Consent capture forms and stored wording
Forms that collect consent are the source of truth for the wording a contact saw. Keep a dated copy of each form version, its fields, the consent checkbox text, and the privacy notice it linked to. Article 7(1) requires you to demonstrate consent, and the form version is the link between a contact's submission and the words they agreed to. Confirm how your version records form edits, since an overwritten form leaves no trace of the earlier wording.
Configuration exports for settings and tracking
Export the system settings that control IP handling, tracking script use, and cookie behavior, and store them with a date and the version that was running. This shows the Anonymize IP setting was on for the period under review and which tracking choices were made. Settings history is not guaranteed to exist in every version, so ask the vendor or check your own environment. Include notes on the cookie lifetime of one year and the local storage device ID when the tracking script is used.
User access and role lists
Export the list of Mautic users with their roles, permissions and status, and record who can view, edit or export contact data. Assessors look for least-privilege access to personal data and evidence that leavers were removed. Mautic uses basic authentication for users, and if you connect a SAML identity provider, keep the provider's records alongside Mautic's list. Review and sign the list on a fixed schedule.
Cron and queue logs showing processing ran
Logs from cron jobs for segment updates, campaign triggers and broadcasts, plus messenger consumer logs, show that suppression and campaign logic was applied on schedule. A contact who objected should not receive later campaign steps, so these logs support the claim that processing stopped. Keep the logs for the review period and note any failed or skipped runs with the action you took. Confirm the retention behavior of your logging setup.
Dated decisions on lawful basis and notice text
Record the lawful basis chosen for each marketing activity, the reasoning, the notice text in force, and who approved it and when. This record is written by your organization, not by Mautic, and it explains why consent was or was not the basis for a processing activity. Keep prior versions of the notice with effective dates so each contact can be matched to the wording in force. Have your legal or privacy team review the record before the assessment.
Configuration sequence for Mautic GDPR consent and objection
This sequence configures a self-hosted Mautic so consent, withdrawal, objection and tracking settings work together for marketing contacts. Each step closes with a record the controller can show an auditor or supervisory authority, and the final test confirms the paths work in production.
Confirm lawful basis and consent wording per channel
The controller's privacy or legal lead records the lawful basis for each marketing channel, such as email and SMS, and approves the consent wording shown at sign-up or import. Under Article 7(1) the controller must be able to demonstrate consent, so each wording version is saved with its date and data source. DeployOpen documents the register and maps each channel to its Mautic configuration. The step closes when a signed consent register lists every channel, its wording version and its source.
Set channel-level Do Not Contact and preference center
Configure the preference center so a contact can remove one channel, which sets Do Not Contact for that channel only, without losing other channels. The withdrawal option must be as easy to use as consent, and Article 7(3) requires the data subject to be told about this before consenting. Pause, frequency limits and removal from categories and segments should also be available there. The step closes with screenshots of the preference center and a test contact whose record shows the expected Do Not Contact flags.
Place the objection notice at first marketing message
Article 21(4) requires the right to object to be brought to the data subject's attention clearly and separately from other information, at the latest at the first communication. The notice is added to the first campaign email and the sign-up confirmation, with a link to the preference center. Objection stops processing for direct marketing under Article 21(2) and (3), so the campaign team confirms that objecting contacts leave the relevant segments. The step closes with rendered copies of the first email showing where the notice sits.
Decide IP anonymization, tracking script and cookie notice
Enable Anonymize IP and decide whether the tracking script is used. Mautic tracking sets cookies with a one-year lifetime and identifies returning visitors by cookie, and the tracking script also stores a device ID in browser local storage. The controller's legal team confirms whether consent is needed before these run and aligns the website cookie notice with the result. The step closes with a settings export and a browser inspection of a test site showing the cookies and local storage, matched to the notice text.
Set frequency limits, categories and segment rules
Set frequency limits for each channel and define categories so contacts can choose the topics they want. Review segment filter rules so that contacts who have withdrawn a channel, paused or objected are excluded from campaigns and broadcasts. Mautic depends on segment and campaign updates, so the rules are tested against real records before launch. The step closes with a test segment in which a withdrawn or paused contact is excluded, with the segment count and filter logic saved.
Verify cron jobs, broadcasts and messenger processes
Confirm that the segment update, campaign update and campaign trigger cron jobs are staggered as the Mautic documentation recommends. Confirm the broadcasts command runs for segment emails and that a messenger consumer is running whenever emails are queued. If a process stops, a withdrawal may not take effect in time, so the platform team checks scheduler logs and queue status. The step closes with logs from a full cycle showing each job ran and the queue drained without errors.
Restrict user roles to consent-relevant permissions
Define Mautic user roles so only authorized staff can edit consent fields, Do Not Contact flags and suppression lists, and so campaign builders cannot change them. Basic authentication or SAML single sign-on is used for staff logins, and SAML requires email, first name and last name attributes from the identity provider. The step closes with a role permission matrix and a test login for each role confirming that restricted actions are blocked and logged.
Test subscribe, withdraw, object and pause paths
Run a documented test script with test contacts through each path: subscribe, withdraw a single channel, object, and pause. For each path, check the contact record, the suppression in campaigns and broadcasts, and the cookie or tracking behavior. Record the date, Mautic version, tester and pass or fail result for every step, and retain the log with the consent register. The step closes with a signed test log covering all four paths, which the controller can use as evidence in a compliance review.
What Mautic does not cover for GDPR marketing compliance
Mautic handles some consent mechanics, such as per-channel Do Not Contact, the preference center and IP anonymization, but it does not settle the legal positions around them. Each item below is owned by the controller or another vendor, and DeployOpen can scope the technical part without deciding it for you. The GDPR requires no certificate, so any certification is a voluntary, separate decision.
Lawful basis and privacy notice
Mautic records consent and preferences, but it does not decide which lawful basis applies to each marketing purpose. If you rely on legitimate interest, the controller must document a balancing assessment per purpose and keep it current when campaigns change. The privacy notice must match what Mautic does, including the tracking cookies and device ID. Article 21(4) also requires the right to object to be shown clearly and separately at the latest at the first communication, so check that welcome emails, forms and preference center text use the same wording as the notice.
Retention and deletion for contacts
Mautic keeps contact records, activity and campaign history until someone removes them, and the retention period is a policy decision. The controller sets how long inactive contacts, unsubscribed records and form submissions are kept, and what happens to each at the end of that period. Suppression entries often need their own rule, because they must persist to honor an objection even after the contact record is removed. Confirm the rules in writing, then confirm how backups, logs and copies sent to integrated CRM or SMS services are handled.
Data subject requests beyond the interface
The contact interface covers some access, correction and erasure tasks, but a full request can reach data outside Mautic, including email provider logs, CRM copies, web analytics, backups and exports. Your team needs a process that identifies every system holding the person's data, records what was done and meets the deadlines in the GDPR. Identity verification before disclosure is also the controller's decision. For the technical part, list where Mautic data flows and which connectors can be queried or purged.
Processor agreements and transfer mechanisms
Hosting providers, email transports and integrated CRM or SMS services usually process personal data on your behalf, which calls for a written processor contract under Article 28. If any of these services are located outside the EEA or access data from third countries, Chapter V requires a transfer mechanism. Check whether the EU-US Data Privacy Framework decision applies to a given provider, and if it does not, which other mechanism covers the transfer. Confirm each vendor's contract terms, sub-processor list and data location before connecting it to Mautic.
Breach notification workflow
Articles 33 and 34 require the controller to notify the supervisory authority of a personal data breach without undue delay and, where the risk is high, the affected individuals. Mautic does not decide severity, assemble the notice or set the internal escalation path, so these steps belong to your incident response process. Define who triages incidents, which logs are retained for investigation, and how each processor reports incidents to you. Test the workflow with a tabletop exercise built on a plausible scenario.
Identity and access controls
Mautic authenticates users with basic authentication and can integrate with a SAML single sign-on identity provider, which must send email, first name and last name attributes. The docs describe no LDAP option, so directory-based access policies and group-driven role assignment need a different design or written confirmation from the vendor. Multi-factor enforcement, joiner and leaver processes and periodic account reviews sit with your identity team. Confirm the SAML setup and the account review process before go-live.
Hosting, cron and release support that keep the GDPR settings working
The consent, objection and tracking settings in Mautic only protect contacts while the platform runs as designed. A Do Not Contact entry recorded in the preference center is data in a database, and it changes outcomes only when every later send, segment update and campaign step reads it on schedule. Treat hosting, scheduled jobs and the message queue as part of the compliance design, and record the decisions about them in the same evidence pack as your configuration. If a suppression exists but the job that enforces it stalls, the suppression has not protected anyone.
The Mautic project states that it should not be installed on shared hosting and recommends a VPS or dedicated server instead. For Mautic 7.0, plan for PHP 8.2, 8.3, 8.4 or 8.5, MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher, and a web server of Apache, Nginx or IIS. npm is also needed, because it is required from Mautic 5.0 onward. Confirm these figures against the requirements page on the day you build, since supported versions change between releases. Ask who owns operating system patching, database backups and PHP upgrades on the server, because on a self-managed host those responsibilities sit with your team or your partner's written scope.
Mautic depends on cron jobs for segment updates, campaign updates and campaign triggers, and the documentation says these should be staggered so they do not compete for the database at the same moment. A broadcasts command sends segment emails, and a messenger consumer must run whenever emails are queued. Give each job a named owner, a log location and an alert that fires when it stops. Then test the enforcement path on purpose: pause a consumer in a non-production copy, confirm that a contact who has objected or withdrawn email consent is excluded from the next campaign or broadcast run after it restarts, and confirm that the alert fires before a backlog builds.
Mautic's stated release cadence is monthly patch releases, minor releases every three months and major releases every two years. The releases page lists Mautic 7.2 (Absolunto) with active and security support until 30 September 2026, Mautic 6.0 (Tabit) with security support until the same date, Mautic 5.2 (Capella) until 30 June 2026, and Mautic 4.4 under paid Extended Long Term Support until 31 December 2026. Mautic 7.3 is planned as the long-term support release, with security support through 31 December 2027. These end dates are fixed, so check the releases page at the time of publication and again before every change window. An installation on an unsupported line keeps running, but it stops receiving security fixes for the code that handles your contact data.
Plan the upgrade path as part of the compliance evidence, not as a later maintenance task. Record the current release line, the date its security support ends, the target line and the PHP and database versions that line requires. Keep test results from a staging copy that mirrors your consent settings, preference center, categories and cron schedule, so you can show that the consent behavior survived the change. Ask any implementation partner to include upgrade stops, rollback steps and the timing of patch windows in the written scope, and to state whether the quote covers routine patches, minor releases, major upgrades or a combination.
What Articles 7 and 21 ask Mautic to prove
Where processing relies on consent, you must be able to show that the person agreed to that specific processing. Mautic does not make this decision for you. Its contact records and timelines hold part of the evidence, but the complete record depends on how you capture and keep consent.
- Consent capture: keep the form, page or confirmation step the contact used, along with the exact wording they saw at that time.
- Contact history: use the contact timeline and segment membership to show when a contact joined a list. Confirm which events your Mautic version records.
- Channel status: Do Not Contact entries show which channels a contact has refused. Export contact status before bulk changes so earlier states are not lost.
- IP handling: the Anonymize IP setting stops storing full IP addresses. Decide whether a full IP address is part of your consent evidence before you enable it, because the setting limits what you can keep.
Check that each consent record names the purpose, the channel and the date, and that your retention rule covers those records.
Withdrawal must be as easy as giving consent, and the person must be told they can withdraw before they consent. In Mautic, the preference center is the main route for withdrawal, and the disclosure belongs on the form or page where consent is collected.
- Channel withdrawal: removing a channel in the preference center sets Do Not Contact for that channel only. Consent given separately for another channel is not withdrawn by this action.
- Lighter options: pausing a contact, setting frequency limits, or removing a category or segment can offer a softer choice. These options do not replace a withdrawal when the person wants consent withdrawn.
- Access: confirm that the preference center link works without a login and appears in every campaign email.
- Withdrawal record: keep the Do Not Contact entry, its date and the channel it covers.
- Disclosure: place the statement that withdrawal is possible in the consent wording at the point of capture.
Test withdrawal on each channel and confirm that the number of steps to withdraw matches the steps needed to give consent.
If you process personal data for direct marketing, the person may object at any time, and processing for that purpose must then stop. This applies to direct marketing processing in general, so it must be handled in your marketing workflow whether or not the contact has given consent. An objection should stop marketing sends and keep the person off future lists.
- Stop sends: channel Do Not Contact prevents contact on that channel. Confirm that campaigns, broadcasts and segment emails in your version respect it before you rely on it.
- Suppression after import: keep a suppression record so a later bulk import does not add the person back.
- Queued messages: campaign and segment updates run through cron jobs, and emails can be queued. Check how long a message can remain queued after an objection and monitor the queue.
- Objection record: log the date, the channel and the purpose the person objected to.
Confirm with your legal team which purposes the objection covers, and test a send after an objection to see whether the contact still receives anything.
The right to object must be brought to the person's attention clearly and separately from other information, at the latest at the first communication. In practice, the first email or message from a campaign should show an objection or preference link that a reader can find without searching.
- Template design: place the objection notice in a clearly labelled block or footer, separate from the marketing copy. Check this in the template your Mautic email builder produces.
- First step of each journey: check the first message in every new campaign, welcome sequence and re-engagement flow.
- Imported contacts: the first communication to a contact from your imported list is still a first communication, so review the notice before the first send to that list.
- Template versions: record the template version and the date it went live with each campaign.
Keep a copy of each template version sent, and check the rendered notice on desktop and mobile email clients.
Mautic GDPR consent setup questions buyers ask before hiring help
What does a Mautic GDPR consent configuration cost?
DeployOpen does not publish prices, and a quote follows the written scope. The fee moves with the number of channels (email, SMS and others), the number of websites and forms that collect consent, and any CRM or email provider integrations, such as the HubSpot or Salesforce plugins. Custom preference center design, the amount of testing and evidence you need, and the number of environments (for example, staging and production) also change the effort. Ask for the quote to split one-time build work from any recurring support or testing retainer, and to list what is excluded, such as legal review of your notice wording.
Can our internal team set up Mautic consent handling alone?
Yes, if you name one owner who understands the lawful basis for each marketing activity and how Mautic handles channels, segments and the preference center. That owner decides what consent means for your business, while the team applies per-channel Do Not Contact settings, the preference center, IP anonymization and cookie review. Teams without a platform specialist often find that testing each channel and recording the evidence takes more time than the configuration itself. An outside review of the finished setup is a common middle path.
How long does a Mautic consent project take, and what sets the timing?
No general duration applies, so the timeline comes from the written scope. The main drivers are the number of channels, sites and integrations in that scope, the state of your existing contact data, and how long your legal or brand approvals take for consent and notice wording. Approval cycles are often the longest step and sit outside the build team's control. Ask for a schedule that shows each dependency, who approves each step, and the dates by which you must supply decisions and wording.
What do we need to provide before a Mautic consent project starts?
Before work starts, you need to supply the following:
- Lawful basis decisions for each marketing activity and channel
- Approved consent and notice wording, including the withdrawal and objection text
- Access to the Mautic instance with a role that allows configuration changes
- Cloud or data center access for the servers, databases and any integration endpoints
- A named decision maker who can approve scope changes and sign off the final settings
Missing items usually delay the schedule more than technical work does, so confirm each one in the statement of work.
Does DeployOpen certify our Mautic setup as GDPR compliant?
No. DeployOpen prepares settings, documentation and evidence that show how your Mautic instance handles consent, objections and tracking. Independent auditors or certification bodies assess that work, and DeployOpen does not issue audit reports, attestations or certifications. The GDPR requires no certificate. Article 42 certification is voluntary, is issued by accredited certification bodies or supervisory authorities, and does not reduce the responsibility of the controller or processor for compliance. Your organization remains accountable for its marketing practices.
How must Mautic prove that a contact gave marketing consent?
The controller must be able to demonstrate that the data subject consented where processing relies on consent (Article 7(1)). Under Article 7(3), consent can be withdrawn at any time, withdrawal must be as easy as giving consent, and the person must be told this before consenting. In practice, configure Mautic so each consent is recorded with its context, and so the withdrawal route, such as the preference center, is reachable from every message. Have counsel confirm that your records and wording meet your obligations, because the configuration alone does not settle that question.
What can go wrong with Mautic cron jobs and channel suppression?
Mautic relies on cron jobs to update segments, update campaigns and trigger campaign steps, and the documentation says these should be staggered. If they run late, stop, or overlap, segment membership can lag behind a contact's latest preference, so a campaign may act on outdated data. Removing a channel in the preference center sets Do Not Contact for that channel only, so each channel needs its own test. Include scheduled job monitoring and a test plan that withdraws consent on each channel, then checks that no later message is queued for it.
Does Mautic store IP addresses and tracking cookies, and what should we check?
Mautic can store full IP addresses for visitors and contacts unless you turn on the Anonymize IP setting, which the documentation describes as supporting GDPR compliance. Tracking cookies have a lifetime of one year and identify returning visitors, and the tracking script also stores a device ID in browser local storage. Review these settings with your legal team, decide whether any tracking needs consent before it runs, and confirm how the cookie banner and script loading behave on each site. Record these decisions, since they form part of the evidence you may need to show later.
How DeployOpen scopes and delivers Mautic GDPR configuration and evidence
DeployOpen configures self-hosted Mautic in your own infrastructure so that consent, objection and tracking settings match the GDPR obligations your marketing team carries. We start from a written scope that names each channel, preference option, tracking setting and evidence record, then build, test and document the result so your team can run it and show how it works.
How we scope
- Engagements are fixed-scope, with the Mautic consent, objection and tracking work agreed in writing before any build starts.
- The written scope lists each marketing channel, its Do Not Contact behavior, and which preference center options are offered to contacts.
- We confirm where your Mautic instance runs, how tracking and IP anonymization are set, and which records your legal team needs to retain.
How we build
- We configure per-channel Do Not Contact, pause, frequency and category options in the preference center to match the approved wording.
- We set the Anonymize IP option, review tracking cookie and device ID behavior, and document what the tracking script stores in each browser.
- We test withdrawal, objection and resubscription paths end to end with sample contacts before anything reaches live audiences.
How we hand over
- You receive configuration documentation mapping each consent, objection and tracking setting to the GDPR article it supports.
- The evidence set describes which contact fields and event logs show that consent was given, changed or withdrawn, and how to export them.
- Your team gets a walkthrough of the preference center, the settings and the test results, with an operating checklist for changes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so changes to Mautic releases are reviewed against the same settings.
- Re-testing after each Mautic upgrade confirms that preference center, tracking and anonymization behavior still matches the documented design.
- Questions about legal interpretation stay with your data protection officer or counsel, and we confirm the technical behavior they rely on.
