How Mattermost data retention and legal hold support GDPR and litigation duties
A compliance lead carries two duties that pull in opposite directions. Mattermost retention policies and Legal Hold cover the technical deletion and preservation mechanics, but the retention periods, the lawful grounds for holding personal data and the legal decisions about when to preserve or delete remain the organization's. Article 5(1)(e) of the GDPR requires personal data to be kept for no longer than necessary for the purposes of the processing, so chat history containing personal data needs a defined end point. At the same time, once litigation, a regulatory investigation or an audit is reasonably anticipated, relevant messages must not be removed by a scheduled job. The platform provides controls for both duties, but your legal and privacy teams must decide how those controls are set before anyone changes a configuration.
Retention policies help with storage limitation. Enterprise and Enterprise Advanced support a global retention policy plus custom policies per team or channel, for both messages and file uploads, run as a daily scheduled job. Deletion through this job is permanent and cannot be reversed, so policies should be tested on a non-production server with representative data before they reach production. From v10.10, retention can optionally keep pinned posts that would otherwise expire, which is a decision your records owner should make explicitly. Article 30(1)(f) asks the record of processing activities to state envisaged erasure time limits for each category of data where possible, and Articles 13(2)(a) and 14(2)(a) require privacy notices to state the storage period or the criteria used to set it. Map each policy to a documented category and confirm that the notice describes what the system actually does.
Legal Hold addresses the preservation side. Through the Legal Hold plugin, available on Enterprise and Enterprise Advanced, you can preserve the data of relevant users for litigation, regulatory investigations and audits, and combine holds with eDiscovery integration and your retention policies. Counsel should define who may place and release a hold, how a hold is scoped to named users, and how each action is documented. Test the precedence between holds and retention jobs on a staging server, so you can show that a held user's messages survive a scheduled deletion run. Confirm with Mattermost how holds treat content that has already been deleted before the hold was placed. A hold also keeps more personal data longer, which conflicts with storage limitation, so set a review date and release holds when the matter closes.
Some decisions stay outside the platform. Mattermost cannot choose retention periods, which depend on your purposes, national and sector rules and your legal advice. It cannot establish the lawful basis for holding messages, and it cannot decide how erasure requests are handled across backups, exports and file storage. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, lasts for at most three years and does not reduce your responsibility for compliance. Ask your auditor which evidence they expect, such as policy records, job logs and hold records. Before you finalize your notices and records, check the current GDPR text, because proposed amendments were still in procedure as of October 2026.
Which GDPR and litigation requirements map to which Mattermost controls
This table maps each GDPR storage and records requirement, plus the litigation preservation need, to the Mattermost setting that addresses it. Read each row from left to right to see what the requirement asks for and which configuration to set. The main takeaway is that retention periods must match what you publish in your records and privacy notices, while legal hold is a separate control for named users, and both retention policies and legal hold require Enterprise or Enterprise Advanced.
| Requirement | What it asks for | Mattermost configuration | Plan needed |
|---|---|---|---|
| Article 5(1)(e) storage limitation | Keep personal data no longer than needed for the processing purpose, in an identifiable form only for that period. | Set a global retention policy for messages and files, then add custom team or channel policies where a shorter or longer period is justified. | Enterprise or Enterprise Advanced |
| Article 30(1)(f) erasure time limits | Record the envisaged time limits for erasing each category of data in the record of processing activities, where possible. | Map each data category to a retention policy scope (global, team or channel) and keep that mapping in the record of processing activities. | Enterprise or Enterprise Advanced |
| Articles 13(2)(a) and 14(2)(a) privacy notices | State the storage period, or the criteria used to set it, in the privacy notice shown to data subjects. | Confirm that the periods configured in each retention policy match the published period. Document the criteria behind each setting. | Enterprise or Enterprise Advanced |
| Litigation preservation need | Keep relevant records intact when litigation, a regulatory investigation or an audit is reasonably anticipated, even where a retention period would otherwise delete them. | Enable Legal Hold through the Legal Hold plugin and add the named users whose data must be preserved. Test the hold before relying on it. | Enterprise or Enterprise Advanced |
| Pinned posts past the retention period | Keep pinned records, such as decisions or agreed terms, that a retention period would otherwise delete. | From v10.10, enable the option that preserves pinned posts exceeding the retention period. Confirm the option is set in every policy that applies to those channels. | Enterprise or Enterprise Advanced |
How Mattermost retention policies delete messages and files
The global retention policy sets one period for messages and one for file uploads across the whole server. Mattermost Enterprise and Enterprise Advanced support it, and a daily scheduled job applies the period to content older than the configured limit. Because the rule covers every team and channel, it forms the baseline that custom policies can refine.
- Scope: confirm whether the setting covers messages, file uploads or both, and which conversation types it reaches in your server version.
- Schedule: confirm when the daily job runs in your environment, since the run time determines when content actually disappears.
- File storage: confirm that removing a file also removes the stored object from your file storage backend, not only the database reference.
- Backups: confirm how long existing backups keep content that the live server has deleted, and whether that matches your documented retention period.
- License: confirm your plan is Enterprise or Enterprise Advanced, because the global policy is not available on lower plans.
Before enabling the global policy, verify the period against your records schedule, the storage backend behavior and the backup expiry settings.
Custom policies apply retention rules to specific teams or channels, so the period can differ by business area. This is useful where some groups hold customer records, regulated data or short-lived operational chat. Each custom policy is evaluated alongside the global default, so the rules must be planned together.
- Inventory: list the teams and channels whose obligations differ from the default, and record who owns each one.
- Precedence: confirm how a custom period interacts with the global period in your version, including which rule wins when both apply.
- New channels: confirm how channels created after a policy is set are assigned, so they do not fall outside the intended rule.
- Test run: apply the policy to a non-production team with dated sample content, then confirm which items the daily job removes.
- Documentation: record the reason and period for each policy, because GDPR Article 30(1)(f) asks for envisaged erasure time limits in the record of processing activities where possible.
Before enabling custom policies, verify the precedence rules, the assignment of new channels and the documented erasure periods with the data owners.
Content removed by a retention job is permanently deleted. Mattermost does not provide a way to reverse that deletion from within the product, so any recovery depends on backups or on archives created before the job ran. Permanent deletion is the mechanism that satisfies storage limitation, and it is also the reason the rules must be checked before they run.
- No undo: treat every retention run as final for the content it selects, and confirm that no one expects recovery from the live server.
- Backups: confirm which backups hold content that the job has deleted, how long they keep it and whether that period is documented in your privacy notices.
- Legal holds: confirm that any legal hold for in-scope users is in place before a retention rule can remove their content. The Legal Hold plugin on Enterprise and Enterprise Advanced can be combined with retention policies.
- Archives: confirm that any archive or export your organization needs for recordkeeping is running before deletion begins, since deleted content cannot be exported afterward.
- Staging: rehearse the full sequence on a copy of the server with representative data, and review the results with legal and records staff.
Before enabling deletion on production data, verify the backup expiry, the legal hold status and the archive status for every affected team and channel.
From Mattermost v10.10, data retention can optionally preserve pinned posts that exceed the retention period. This lets teams keep important decisions or reference material in place while the rest of the conversation is removed. The option is off unless an administrator enables it, so the default behavior still deletes pinned content on schedule.
- Version: confirm that your server runs v10.10 or later, because earlier versions do not offer this option.
- Enablement: enable the option deliberately, and confirm its exact name and location in the admin console for your version.
- Attachments: confirm whether files attached to preserved pinned posts are also kept, since the storage impact depends on it.
- Ownership: agree who may pin posts and who reviews pins, because preserved content stays beyond the normal period.
- Minimization: assess whether preserved pins still meet the purpose of processing under the storage limitation principle, and document the criteria for keeping them.
Before enabling pinned post preservation, verify your server version, confirm the attachment behavior with a test post in a non-production channel, and confirm the review process for pinned content.
When a Mattermost legal hold overrides data retention
A legal hold changes what the retention job is allowed to delete, so the team should settle its design before anyone enables it. On Enterprise and Enterprise Advanced, the Legal Hold plugin preserves the data of relevant users for litigation, regulatory investigations and audits. It can be combined with eDiscovery integration and with retention policies, so a retention schedule can keep running for the wider workspace while held users' data stays in place. The platform applies the hold, but counsel decides whether a hold is needed, which users and content it covers, and when it must change. Engineering and compliance teams should treat the hold as a legal instruction that the platform carries out, and document it that way from the start.
Three roles need named owners before the first hold is applied. The first is the issuer, usually legal counsel or an authorized in-house lawyer, who should provide a written instruction that states the matter, the scope and the date. The second is the person who identifies the named users, who must map the matter to accounts. That mapping should include users who have left the organization, shared or bot accounts, and any channels or direct messages those users took part in. The platform only preserves what it is told to preserve, so an incomplete list is a preservation gap. Confirm with Mattermost which objects a hold covers (users, channels or teams) and how the plugin reports what it has preserved, because the answer determines how the identification step is run.
Ending a hold is as important as starting one. Release should happen only on a written instruction from counsel, and the release should be recorded with the same care as the original hold. The team should confirm how the plugin releases a hold, what happens to content that was preserved while the hold was active, and when the normal retention job will resume deleting it. Ending a hold without authority can undermine a defensible preservation position, while keeping it indefinitely conflicts with the storage limitation principle in Article 5(1)(e) of the GDPR. Counsel should therefore record the legal basis for any extended retention of personal data, and the privacy team should check that the record of processing activities still reflects the actual time limits.
The retention schedule and the hold must be tested together. Retention runs as a daily scheduled job, and permanent deletion is irreversible, so content deleted before a hold is applied cannot be recovered by the hold. Apply holds promptly after a matter is identified, and confirm in a non-production environment that a held user's messages and files survive a full retention run while other users' content is still removed on schedule. Keep a log of the hold start, the named users, the retention policies in force and the test results. Review the holds regularly with counsel, because a hold that outlives its matter keeps personal data that the GDPR would otherwise require to be erased.
What evidence Mattermost retention and legal hold produce for auditors
Auditors will ask whether the configured retention policy matched what ran, who was placed under hold, and who approved each hold. The cards below cover those four questions, with the source of each record in your self-hosted environment and how to keep it. Confirm the exact log lines and export formats in your deployed version before promising them to an auditor.
Retention policy configuration snapshot
Keep a dated record of every global and custom retention policy, including the team or channel scope, the message and file retention periods, and whether pinned posts are preserved (available from v10.10). In a self-hosted deployment, the settings appear in the System Console and the policy data sits in your PostgreSQL database, so the snapshot should draw on both. Store a copy with each policy change ticket so you can show which policy applied on any given date. Confirm whether your version offers an export or API call that covers this, or whether the snapshot must be taken manually.
Schedule of retention runs
Retention runs as a daily scheduled job on Enterprise and Enterprise Advanced. Evidence that each run happened sits in the server logs on the nodes you operate, and it should show start and finish times and any errors. Ship those logs to a central store with a retention period set by your records schedule, and keep the job schedule itself under configuration control. Confirm which log entries and counts your deployed version writes, because a run that failed may look similar to a run that deleted nothing.
Legal hold roster with dates
The Legal Hold plugin records which users are under hold and the hold's start and end dates. Export the roster when each hold starts, after every change in scope, and at closure, so you can show who was covered on any given day. Where no end date is set, record that the hold is open-ended and name the person who decides its closure. Confirm which fields your plugin version displays and whether the roster can be exported in a form you can file, since a screen view alone is weak evidence.
Approval trail for each hold
Each hold needs a recorded requester, approver and legal basis, such as a litigation matter or a regulatory request. Mattermost may not capture the full approval chain itself, so link each hold ID to a case or ticket record kept by legal, with timestamps and sign-off. Record changes to hold scope in the same trail. Confirm what the plugin stores about who created or modified a hold, and treat any gap as a process step to close before the hold takes effect.
Deletion and preservation overlap records
Permanent deletion is irreversible, so the evidence must show what was removed and what a hold or pinned post protected on that date. Keep the policy snapshot and the hold roster that were active on each run date, so the two can be read together. This matters most where a hold overlaps a retention period, because content is protected only while the hold is active. Before relying on this picture in a dispute, test in a non-production environment how deleted and held content appears in your logs.
Configuring retention and legal hold in the order a compliance review expects
This sequence moves from confirming what your Mattermost plan supports to proving that retention and holds work as the approved schedule says. Each step ends with a signed record, so a reviewer can trace every setting back to a decision and an owner.
Confirm the plan level for each feature
Confirm with your account contact that your subscription is Enterprise or Enterprise Advanced, since the global and custom retention policies and the Legal Hold plugin are available on those plans. Check the plan name, license term and seat count against the contract. The platform owner signs the change ticket with these details. The step is done when the plan is confirmed in writing and the record is filed with the retention project.
Document retention periods with the privacy team
Agree a retention period for each data category, such as channel messages, direct messages and file uploads, and record the criteria behind each period. GDPR Article 30(1)(f) expects time limits for erasure where possible, and Articles 13(2)(a) and 14(2)(a) require privacy notices to state the storage period or the criteria used to set it. The data protection officer or privacy lead approves the schedule. The step is done when the approved schedule is versioned and dated.
Set the global retention policy
Enter the approved global periods for messages and file uploads in the System Console. The policy runs as a daily scheduled job, and permanent deletion cannot be reversed, so check each value against the approved schedule before saving. A second reviewer compares the saved values with the schedule line by line. The step is done when the settings match the schedule and the privacy lead and platform owner both sign the change record.
Add custom policies for teams and channels
Create custom policies only for teams or channels whose records need a period different from the global one, such as a regulated business unit. Keep the list short, because each exception needs a stated justification. Each custom policy applies to messages and file uploads in its scope. The privacy lead approves each exception with the business owner. The step is done when a register lists every team or channel, its period, its justification and its owner.
Decide how pinned posts are handled
From Mattermost v10.10, retention can optionally preserve pinned posts that exceed the retention period. Decide whether pinned posts are kept as records or deleted with other content, because pinned posts often hold decisions or approvals. Write the decision into the schedule from step two and confirm your server version supports the option. Legal counsel and the privacy lead sign the decision. The step is done when the choice, the version and the approvers are recorded together.
Configure Legal Hold and the eDiscovery integration
Enable the Legal Hold plugin on your Enterprise or Enterprise Advanced server. Define who may place a hold on named users, how each hold is scoped and how it is released, since holds suspend deletion for the users concerned and can be combined with retention policies. If you use an eDiscovery integration, confirm its connector and export path with the vendor. Legal counsel authorizes the hold procedure and the platform owner signs the configuration. The step is done when hold roles and the release procedure are written down.
Test a hold on a non-production dataset
Copy a dataset into a non-production environment, set a short test period, place a hold on a test user and wait for a scheduled run. Confirm that held content survives and unheld content is removed as expected. Never run this test against production, because deletion is irreversible. QA or a security engineer runs the test and records the results, and legal counsel reviews them. The step is done when the report shows the expected outcome and any gaps are logged with owners.
Record each setting as evidence
Export or capture each setting, including the approved schedule, custom policy register, pinned post decision, hold procedure, test report and server version, and store them together in a dated evidence pack. Link each configuration change to a change ticket. The data protection officer accepts the pack and reviews it after each platform upgrade. This pack supports your own accountability under the GDPR, which requires no certificate, so the step is done when the pack is indexed and approved.
What Mattermost retention and legal hold do not cover
Mattermost applies retention and legal hold to data on the server, but several GDPR and litigation obligations sit outside the product. The cards below list each gap, why the platform does not close it, and which role should own the decision. Assign owners before the policy is enabled so the first deletion run is a planned action.
Choosing lawful retention periods
Mattermost deletes data once the period you enter for the global policy, a team or a channel has passed, and its daily job runs without judgment about the content. The platform cannot decide how long your organization needs messages and files for their purpose. Set periods by data category, record the reasoning for each, and check them against sector rules that apply to your business. Deletion is irreversible, so test the policy on a non-production copy first. Owner: the data protection officer with legal counsel and the business owner of each team.
Legal basis for keeping data
Article 5(1)(e) limits storage to what is necessary for the purpose of processing. A retention setting records a number of days, not the reason that justifies keeping each category of messages and files. Document which purpose supports each period, including the grounds for any legal hold, and link that record to your record of processing activities. Review it when teams, products or regulatory expectations change. Owner: the data protection officer, with HR, legal and the business owners who can explain why the data exists.
Erasure requests in backups and exports
The retention job removes data from the live Mattermost database and file storage. Copies in backups, snapshots, compliance exports and archives keep the data until their own schedules expire. An erasure request must either reach those copies or rest on a documented reason to keep them. Confirm backup rotation periods, the locations where export files are written, and how a request is traced across each copy. Owner: the platform team for backups, with the privacy team running the request workflow.
Copies outside the server
Messages and files can persist on user devices, in desktop and mobile client caches, in notification emails if your configuration sends them, and in connected integrations. The server retention policy does not reach those copies. Inventory where message content travels, how long each client keeps it, and which integrations receive it. Confirm client-side behavior for your client versions and device management settings, since it depends on the build in use. Owner: IT and endpoint management, with security reviewing integrations.
History imported before the policy
Retention applies from the point the policy takes effect. Messages migrated from Slack, Rocket.Chat or another source before that point, and posts created before a stricter period was set on a channel, fall outside the new schedule until you act on them. Decide whether historical data is kept, trimmed or deleted, and record the date each policy took effect. If you enable the option that keeps pinned posts beyond the period, document that choice as a separate exception. Owner: the migration lead, with the data protection officer approving the treatment of imported history.
Storage period wording in privacy notices
Articles 13(2)(a) and 14(2)(a) require privacy notices to state the storage period or the criteria used to set it. If the notice describes a retention period that differs from the configured policy, the notice is inaccurate even when the platform works as configured. Align the wording with the retention settings, update it whenever a period changes, and check the record of processing activities at the same time. Owner: the data protection officer, with communications or legal review before publication.
Why GDPR storage limitation needs a documented retention schedule
A documented retention schedule should exist before any Mattermost setting is changed, because GDPR storage limitation requires you to justify every retention period you apply. Article 5(1)(e) requires personal data to be kept in a form that permits identification of individuals for no longer than is necessary for the purposes of the processing. In a chat platform those purposes differ. Channel messages, direct messages, uploaded files and account records may each have a different reason to exist, so one period applied to everything is hard to justify. The schedule records each category of data, its purpose, and the period or criteria that apply to it.
Two documents outside the server must agree with that schedule. Article 30(1)(f) asks your record of processing activities to state the envisaged time limits for erasure of the different categories of data, where possible. Articles 13(2)(a) and 14(2)(a) require privacy notices to state the storage period or the criteria used to set it. If your notice describes one period and the platform deletes on another, any assessor or data subject who compares the two will see the gap. Build the schedule as one table with columns for data category, purpose, period or criteria, owner, and the Mattermost setting that enforces it, then carry the entries into both documents.
Read the EDPB's news item of 18 February 2026 on challenges hindering the full implementation of the right to erasure before you finalize the table. It is a prompt to check where personal data exists beyond the primary database and file store. For a self-hosted Mattermost, confirm with your own team which copies exist, such as database and file backups, exports, search indexes, logs and any archiving system, and how long each is kept. Record the answers as separate rows or notes in the schedule. A policy that removes messages from the live system while copies persist can leave the schedule describing only part of the data. Confirm these points with your data protection officer and counsel, not only with the platform team.
The schedule is a design decision, so make it before you configure anything. Mattermost Enterprise and Enterprise Advanced support a global retention policy plus custom policies per team or channel for messages and file uploads. These run as a daily scheduled job, and permanent deletion is irreversible. Decide in advance whether pinned posts should be preserved past the retention period, since that option is available from Mattermost v10.10. Also decide which legal holds override deletion and who approves them, because the Legal Hold plugin on those plans suspends deletion for named users and can be combined with retention policies. A schedule that is approved and dated before the first policy runs shows that deletion followed a plan.
Questions buyers ask about Mattermost retention, legal hold and GDPR
What drives the cost of Mattermost retention and legal hold work?
Cost depends mainly on how many teams, channels and direct message groups need their own retention period, because each distinct period becomes a policy to design, configure, test and document. Existing chat history matters too, since data already on the server must be mapped to the new periods before the first scheduled deletion runs. The number of legal hold scenarios, whether eDiscovery integration is in scope and the evidence your counsel or auditors expect all add work. One-time costs cover design, configuration, testing and the operating runbook. Recurring costs appear only if you retain a partner for periodic policy reviews or hold requests. Ask any quote to itemize these components, show who owns each step, and show the Mattermost Enterprise subscription separately from the services.
How long does it take to configure and test Mattermost retention policies?
Duration depends on the written scope, mainly the number of retention periods, the volume of existing history and the approval steps your legal, privacy and IT owners require before a policy goes live. DeployOpen does not publish a timeline. The duration is set out in the written scope agreed before work starts, so ask for the phases, the approval gates and the dependencies on your side. Testing should cover a policy run against a non-production copy, a check of how pinned posts behave on Mattermost v10.10 or later, and a legal hold test on a named test user. Each approval gate adds waiting time that the implementation team does not control. Confirm your Mattermost server version before estimating, because behavior can differ between releases.
What do we need to provide before a partner starts Mattermost legal hold setup?
Expect to provide sign-off from three groups. Legal decides what must be preserved, for how long and under which triggers. Privacy sets the retention periods and the storage period statements used in your records of processing and privacy notices. IT provides access, the Enterprise plan license and an operational owner for the daily retention job. Also provide the list of teams and channels, any existing retention rules, the archive or eDiscovery systems in use and the hold triggers your counsel recognizes. Decisions made late cause rework, especially when a deletion job has already run. Before the engagement starts, get named approvers, a decision log and an agreed change window in writing, and confirm whose sign-off closes each step.
Can our internal team set up Mattermost retention and legal hold themselves?
Yes, if your team has Mattermost administration experience, access to the PostgreSQL database and someone who can translate legal and privacy requirements into concrete policy settings. The configuration itself is usually the smaller part of the work. The harder parts are the decisions: which periods apply to which teams, what must survive a deletion job and how a hold is evidenced and released. Internal teams often underestimate testing and the runbook for handling hold requests during staff changes. Many organizations split the work, keeping decisions and daily operations in-house while a partner designs the policy set and tests it. Check your skills against the written scope before deciding.
Does a Mattermost legal hold make us GDPR compliant?
No. A legal hold preserves the data of named users for litigation, regulatory investigations or audits, and it can be combined with eDiscovery integration and retention policies. It does not make the organization compliant with the GDPR or any other regime. GDPR compliance depends on a lawful basis, transparency, security of processing under Article 32, data subject rights and storage limitation under Article 5(1)(e), among other duties. A hold also extends how long some personal data is kept, so while it is active the retention must be justified, documented and released when the hold ends. Record the hold basis in your records of processing activities and review it with privacy counsel.
Does GDPR require a certificate for our Mattermost data retention setup?
No. The GDPR requires no 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 or processor's responsibility for compliance. A certificate therefore does not make a retention setup compliant, and a missing certificate does not mean non-compliance. Ask instead for evidence: documented retention periods, records of processing entries that state time limits for erasure under Article 30(1)(f), privacy notices that state storage periods or the criteria used to set them, and test records. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
Which Mattermost plan do we need for retention policies and legal hold?
Retention policies and legal hold both require the Enterprise or Enterprise Advanced plan. Enterprise and Enterprise Advanced support a global retention policy plus custom policies per team or channel for messages and file uploads, and legal hold runs through the Legal Hold plugin on those plans. Professional does not cover these controls. Confirm the plan with Mattermost before scoping, because plan features can change, and ask the quote to name the plan the work assumes. Plan levels also affect related requirements: high availability and FIPS 140-3 compliance are listed from Enterprise, and air-gapped deployment is listed for Enterprise Advanced. Mattermost sells these plans as prepaid annual subscriptions based on seat licenses, and its pricing page lists no public prices.
What happens to deleted Mattermost messages under a retention policy?
Permanent deletion under a retention policy is irreversible. Mattermost Enterprise and Enterprise Advanced run retention as a daily scheduled job, applying the global policy and any custom policies to messages and file uploads. Because deletion cannot be undone, test each policy against a copy first and confirm the scope with the owners of each channel. From Mattermost v10.10, retention can optionally preserve pinned posts that exceed the retention period. Keeping them should be a deliberate decision recorded in the policy, not a default nobody reviewed. Also confirm how your backups handle deleted content, because copies kept outside Mattermost may still hold data that your privacy team needs to address.
How DeployOpen scopes and delivers Mattermost retention and legal hold configuration
DeployOpen plans, configures, documents and hands over Mattermost retention and legal hold inside infrastructure you control. Retention and holds are set against your records obligations, litigation exposure and GDPR storage limits, so deletion and preservation are decided before anything is switched on. Most engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names the Mattermost edition, plan level and deployment model the retention and hold design depends on.
- Retention scope lists each team, channel, file type and DM population that the policy covers, and which are excluded.
- Records owners, legal counsel and HR sign off on retention periods and legal hold criteria before any build starts.
How we build
- Configure the global retention policy and any custom per-team or per-channel policies on a non-production Mattermost first.
- Test that the daily retention job deletes only expired messages and files, using seeded test data with known ages.
- Enable pinned-post preservation only where your policy needs it, available from Mattermost v10.10 onward.
How we hand over
- Documentation maps each retention rule to its record category, owner, purge schedule and related privacy notice wording.
- A legal hold runbook covers who places and releases holds, how users are selected and how holds are logged.
- Operators receive a verification checklist covering holds, the retention job and any eDiscovery integration.
How we support
- Ongoing support is available as a retainer to recheck retention and hold settings after each Mattermost release.
- Retention periods are reviewed when GDPR guidance changes or pending EU proposals are adopted, as your counsel advises.
- DeployOpen does not issue audit reports or certifications, so your auditors and counsel assess the final configuration.
Sources and further reading
- Mattermost docs: Data retention policy ↗
- Mattermost docs: Legal hold ↗
- Regulation (EU) 2016/679 (GDPR), EUR-Lex ↗
- EDPB news: challenges hindering the full implementation of the right to erasure ↗
- Regulation (EU) 2025/2518 on procedural rules for GDPR enforcement ↗
- Legislative Observatory: procedure 2025/0130(COD), Omnibus IV ↗
