docs/main/administration-guide/manage/admin/content-flagging.mdx
Data Spillage Handling helps prevent accidental data spillage and helps system administrators respond quickly to potential leaks without disrupting collaboration. Enabling this feature empowers Mattermost users to report messages that may contain sensitive, regulated, or inappropriate information, and enables designated content reviewers to assess and take appropriate action by removing or dismissing quarantined messages.
By making every team member a first line of defense against sensitive-data exposure, Data Spillage Handling strengthens mission-critical, secure deployments and supports compliance with organizational and regulatory data-handling standards.
You must be a System Admin in Mattermost. You need to identify who will be content reviewers for quarantined messages, and you need to decide whether quarantined messages should be hidden from users in Mattermost while under review.
Data Spillage Handling isn't enabled by default. To enable Data Spillage Handling:
Alternatively, you can configure Data Spillage Handling via the config.json file or through environment variables.
Under Content Reviewers, define who should review quarantined content:
Choose reviewers carefully. Assigning reviewer roles grants access to potentially sensitive information and may expose data from private channels.
A global reviewer can view quarantined messages from all teams and channels, including private channels they’re not a member of.
Team-specific reviewers can view quarantined messages from their assigned teams, including private channels within those teams they’re not members of.
Additional reviewers: Optionally include:
Under Notification Settings, specify who receives updates at each stage of the quarantine workflow when content is quarantined or reviewed:
All notifications are sent via the Data Spillage Bot as direct messages.
Under Additional Settings, configure how the quarantine workflow behaves:
We recommend enabling Hide message from channel while it is being reviewed and require comments from both reporters and reviewers to maintain transparency, accountability, and an auditable record of actions.
</Tip>When a user quarantines a message, the Data Spillage Bot sends a direct message to all content reviewers.
Direct messages from the Data Spillage Bot is a centralized moderation queue, where reviewers can view, assign, and act on quarantined messages without leaving Mattermost. Reviewers can use it to monitor potential data spills, coordinate response, and maintain an auditable record of review activity.
Each quarantined message appears as a card-formatted message that includes:
Reviewers can select View details to take action as follows:
Once an action is taken, the Status field updates automatically. The Data Spillage Bot sends follow-up notifications to the reporter, author, and other reviewers based on how Data Spillage Handling is configured.
Reviewers can generate a downloadable report that captures the full context of a quarantined message and the associated review activity. Reports are useful for record-keeping, incident response, and preserving evidence before a message is permanently removed.
A report can be generated from any of the following entry points:
If you choose to skip the report download from the Remove message or Keep message flow, Mattermost asks you to confirm that you're proceeding without a report. The skip decision is recorded in the audit log.
If report generation fails (for example, due to a network interruption or session timeout), the dialog displays an error and offers a retry option. You can also skip the report and proceed with the action, or cancel and download the report later from the message details.
Each time a reviewer generates a report, the Data Spillage Bot notifies all content reviewers so an auditable record exists whenever a copy of the potentially spilled data is obtained.
<Tip>We recommend generating a report before removing a message. Once a message is removed, its content, attachments, and edit history are permanently deleted and can't be recovered.
</Tip>Each report is a ZIP archive containing YAML metadata files and the original file attachments. YAML is used because it's both human-readable and machine-parseable, which makes the report suitable for manual review and for ingestion by downstream compliance or incident-response tooling.
The archive has the following structure:
/
├── report_metadata.yaml
├── content_review.yaml
├── post/
│ ├── post.yaml
│ └── attachments/
│ └── <original attachment files>
└── edit_history/
└── <edit_post_id>/
├── post.yaml
└── attachments/
└── <original attachment files>
post.yaml and an attachments/ directory in the same format as the base post directory.To avoid duplication, attachment files are deduplicated across the entire archive by their file ID. Each unique attachment appears exactly once — under the base post if it exists in the current version of the message, or under the earliest edit-history entry that referenced it.
When a reviewer permanently removes a quarantined message, the message and all associated data are deleted from the database and file system and can't be recovered. The deletion covers:
When a reviewer selects Remove message, the Data Spillage Bot posts a Post Deletion Report into the reviewer's content review thread for that quarantined message. The report is delivered to every reviewer who received the original quarantine notification, and is localized to each reviewer's language. Each post includes a short summary rendered inline, and a full report attached as a Markdown file named deletion_report_<post_id>.md.
The report records every cleanup step performed against the message and its associated data. The steps map directly to the data scope listed in Deleted messages:
Each step is assigned one of the following statuses:
When every step is Removed or Not applicable, no further action is required. The report serves as the auditable record of the deletion.
When any step reports Partial or Failed, the report displays an incomplete warning. Reviewers should escalate to a System Administrator, who can use the attached deletion_report_<postId>.md file - including the full per-step error log - to perform manual remediation and confirm that the data is fully removed.
The post deletion report is the single source of truth for post-removal auditing. It isn't stored elsewhere in the System Console, so the reviewer thread containing the report should be retained in line with your organization's audit retention policy.
</Note>Before rolling out Data Spillage Handling organization-wide, we recommend communicating that the feature protects both users and the organization from accidental data spillage. Start with a pilot team to validate reviewer notifications and workflows, integrate the process with existing data-handling or incident-response playbooks, and require reporter and reviewer comments to ensure every decision is transparent and auditable.