Which compliance requirements Mattermost exports help you meet
Mattermost compliance exports help you produce recordkeeping evidence for records protection, in the sense of ISO/IEC 27001:2022 control A.5.33, and some of the access control evidence that surrounds it. On their own, they do not satisfy PCI DSS, DORA, the Swift Customer Security Controls Framework, SEC IT general controls or the FTC Safeguards Rule. DeployOpen plans and builds the export pipeline, prepares the configuration, runs the checks and assembles the supporting evidence in your infrastructure. DeployOpen does not issue audit reports, attestations or certifications. Independent assessors, Qualified Security Assessors and certification bodies make those determinations.
Each regime asks for something different, so the export answers only part of each one. PCI DSS applies to the cardholder data environment and to any system that could affect it, and the payment brands decide who must validate. Assessments are documented as a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Under DORA, the relevant evidence is the register of ICT contractual arrangements, exit plans and contract terms on data location and return. The SEC's guidance points to access to programs and data as an IT general control area, and the FTC Safeguards Rule requires multi-factor authentication for information system access unless the Qualified Individual approves an equivalent control in writing. Those items sit in your identity, access and contract records, not in the export.
The export itself covers direct messages, file uploads, plugin posts, bot and webhook posts and channel member history. It is available on Enterprise and Enterprise Advanced plans and can feed Smarsh (Actiance) Vantage, Global Relay, Proofpoint or CSV output. For self-hosted deployments, files are written to the exports subdirectory of your configured file store, either local storage or S3, or to an alternate file store target using S3 presigned URLs. Decide who can read that location, how it is encrypted and how long exported files are kept, because those controls are what a reviewer will test for records protection. Confirm with Mattermost which archive connector versions your plan supports before you commit to a target.
The most important limit is history. Exports do not include posts made before the feature was enabled, so the cutover date is a control point that an assessor will ask about. Self-hosted deployments can export earlier history with the export command line tool, but that output must be handled and documented as its own evidence set. Before go-live, record the enablement date, the scope of channels and users, and the period you intend to cover. Ask your assessor or regulator which period and record types they expect, and map each requirement ID to the evidence owner, the artifact and the review date.
Mapping each requirement to the export capability and its configuration
This table maps each supplied control requirement to what the Mattermost compliance export does, the configuration it needs, and how far it contributes to that requirement. Read the coverage column as the export's contribution, not as your organization's compliance status, because most rows also depend on your policies, contracts and identity controls. Compliance exports require the Enterprise or Enterprise Advanced plan, and no row is satisfied by the export alone.
| Requirement | Mattermost capability | Configuration needed | Coverage |
|---|---|---|---|
| ISO/IEC 27001:2022 Annex A control A.5.33 (protection of records) | Writes compliance exports to the exports subdirectory of your file store | Restrict access to the export path, enable encryption at rest, and set retention and legal hold rules | Partly |
| PCI DSS v4.0.1 scope | Exports include any message or file posted, including card data if users share it | Document whether cardholder data can be posted; if so, treat the archive as in scope | Not at all |
| DORA Article 28(3): register of information | No register function; the export does not record contractual arrangements | Record Mattermost as an ICT service in your register, with hosting location and contract terms | Not at all |
| DORA Article 28(8): tested exit strategy | Exports to CSV or archive platforms provide a documented data path out | Test an export, reload it into the target platform, and document the transition plan | Partly |
| DORA Article 30(2): service location and data return | Self-hosted data stays in the storage location you choose, and exports support data return | Set storage location and export targets, then reflect them in your provider contract terms | Partly |
| Swift Customer Security Controls Framework v2026 | Compliance export does not address Swift CSP control requirements | Confirm with your assessor whether the archive falls within Swift scope | Not at all |
| SEC Release 33-8810 ITGC areas: access to programs and data | Export output lands in a file store you control, so access follows storage permissions | Limit who can run exports and read the exports path, and review that access regularly | Partly |
| FTC Safeguards Rule 16 CFR 314.4(c)(5): multi-factor authentication | Export does not provide multi-factor authentication | Enforce MFA through your identity provider, or document an equivalent control approved in writing by the Qualified Individual | Not at all |
Where self-hosted compliance exports land and who can read them
On a self-hosted deployment, the file store is part of the archive. Mattermost writes compliance exports to the exports subdirectory of the configured file store, which is either local storage or an S3 bucket. If you send exports to an alternate file store target, Mattermost uses S3 presigned URLs to deliver them there. Choose the location before you enable exports, because that choice determines which systems, accounts and administrators can reach the files, and it is the first access decision in the evidence chain.
The export format depends on the archive provider you select. Mattermost supports Smarsh (Actiance) Vantage, Global Relay, Proofpoint and CSV, on the Enterprise and Enterprise Advanced plans. Each export can include direct messages, file uploads, plugin posts, bot and webhook posts, and channel member history. Confirm with your provider which of these content types its ingestion accepts, how it expects the package to be structured, and whether CSV requires a separate loading step on its side. Get the provider's ingestion requirements in writing before you test with production data.
Once exports land, the file store's controls apply to the records. Review who holds administrative credentials for the storage account, bucket or volume, and who can list or download objects in the exports location. Confirm encryption at rest and in transit, and confirm which retention or immutability features the storage platform provides and how they are configured. For alternate targets, treat presigned URLs as bearer links: anyone who holds one can fetch the object until it expires, so set the expiry window deliberately and confirm how links are issued and logged. Your auditors will ask who could have read or altered an export, so the answer must come from the configuration.
The control logic is straightforward. ISO/IEC 27001:2022 Annex A control A.5.33 concerns protecting records from loss, destruction, falsification, unauthorized access and unauthorized release. Your export location should therefore show a documented chain of custody: where each export is written, who can access it, how access is logged, how long it is kept, and how the handoff to the archive provider is confirmed. Map each of these points to an owner in your own environment, and record the mapping so that the controls can be shown to an assessor without reconstruction.
Before you rely on the export path, run a short set of checks. Confirm that the exports location is separate from general-purpose file storage and that only named roles can read it. Verify that a test export arrives at the archive provider with the expected content types, including direct messages and file uploads. Restore or retrieve one test export end to end and record the steps. Finally, document the schedule for reviewing access to the export location, because the archive is only as trustworthy as the storage and credentials that sit beneath it.
What evidence the export produces for auditors and how to keep it
Auditors judge a compliance export by the set of records around it, not by any single file. The six artifacts below cover the license, the export configuration, the files written, the storage trail, the provider's receipts and the change history that connects them.
Plan and license configuration
Compliance export is available only on Enterprise and Enterprise Advanced plans, so the first thing an auditor may ask for is proof of the plan and seat license in effect when exports ran. Keep the subscription record from your Mattermost account team, the license details shown for the server, and a dated copy of that view each time the plan or seat count changes. Check that the license covered the entire export period, since a lapse or downgrade can stop the feature. Ask Mattermost to confirm in writing what happens to exports when a license expires.
Export settings and target
The export configuration shows which formats were enabled (Smarsh Vantage, Global Relay, Proofpoint or CSV), which channels and users were in scope, and where files were written. For self-hosted deployments the target is the exports subdirectory of the configured file store, or an alternate file store target that uses S3 presigned URLs. Save a copy of the settings with secrets removed, and record the date and reason each time a value changes. Reviewers will compare these settings against the retention rules in force on the export dates.
Exports directory listing and retention
The exports subdirectory holds the files the archive provider receives, so auditors ask for a listing that shows file names, sizes, timestamps and the export run each file belongs to. Take a periodic listing or inventory with checksums, and keep it with the export run records. Set a written retention period for the export files themselves, separate from the message retention policy, and confirm who may delete or overwrite files in this folder. A listing shows what existed when it was taken. It does not show that the export content was complete.
Access logs and permission records
The export folder sits in ordinary storage, so the bucket or volume has its own access trail that is separate from Mattermost application logs. Auditors ask who could read, write or delete export files and whether those rights were reviewed. Keep the storage policy or IAM configuration, group membership records and access logs for the export folder, retained for the period your records policy sets. Confirm that the Mattermost service account holds only the rights it needs for writing exports. Collect both the storage provider logs and the application logs.
Delivery records from the archive provider
Smarsh, Global Relay, Proofpoint or a CSV consumer keeps its own record of what it ingested. Ask each provider for ingestion or delivery confirmations that reference export run identifiers and file counts, and store them alongside your directory listings. Any gap between files written and files received should be investigated and documented with how it was resolved. Confirm with the provider what their confirmations contain and how long they keep them.
Change records for configuration
Auditors look for evidence that export settings, retention rules and the file store target changed through an approved process. Keep a change record for each modification with the date, requester, approver, the previous and new values, and the reason. For infrastructure changes such as moving the file store, link the ticket or pull request that made the change. No single change record proves that a control operated, so pair these entries with your existing change management process and its approvals.
Configuring compliance export in order
This sequence takes a Mattermost deployment from a confirmed plan level to a validated, documented compliance export that your archive provider can ingest. Each step closes with a record that reviewers can check later. Confirm the order before enabling anything, because posts made before the feature is switched on are not included in the export.
Confirm the Mattermost plan level
The Mattermost administrator checks the license in the System Console and confirms the deployment is on the Enterprise or Enterprise Advanced plan, since compliance export is available only on those plans. Record the plan name, license expiry date and server version in the change ticket. This step is complete when the license details are saved with the deployment record and the records and IT owners agree that the feature is available on this server.
Decide the archive target and provider requirements
Compliance exports support Smarsh (Actiance) Vantage, Global Relay, Proofpoint and CSV. The records owner chooses one target and asks the provider in writing which file format, delivery method, naming convention and retention rules it expects, and whether it needs a dedicated account or credentials. The output is a written requirements note, signed off by the records owner, that fixes the format every later test must match.
Choose the file store and set permissions
Decide whether exports will be written to the exports subdirectory of local file storage or S3, or to an alternate S3 target reached through presigned URLs. Give the Mattermost service account write access to that location and restrict other access, because export files contain full message history. Confirm the path with a test write from the Mattermost server. The output is an access map showing who can read, write and delete files in the export location.
Enable export and run test messages
Turn on compliance export in the System Console and apply the settings the records owner approved, including the target and format. Post a marker message in a test public channel and another in a direct message between two test accounts, then run an export. Record the export job details, the marker text, the timestamps and the channel names, so you can find each test message in the output file.
Confirm plugin and bot posts are captured
Compliance exports include plugin posts and bot or webhook posts, so test each source type your organization relies on. Trigger one plugin message and one integration or webhook post in the test channel, then check that each appears in the export with the correct sending account or bot identity. The output is a capture checklist for each source type, with any gaps logged as open issues before go-live.
Verify exported files open in the target format
Open the exported files and check them against the format the provider specified. For CSV, confirm the columns, character encoding and how file attachments are referenced. For Smarsh, Global Relay or Proofpoint, use the provider's validation tools or a test ingestion where the provider offers one. The output is a validation report listing file names, record counts and any fields that failed to parse, which the provider has reviewed.
Document the procedure and scope presigned URL access
Write the runbook covering the plan check, archive target, storage paths, service account, test evidence and the gap before the feature was enabled. Document the export command line tool as the route for past history, and state who can run it. Where an alternate S3 target uses presigned URLs, limit each URL to the required object, keep its expiry short and record who may generate them. The output is an approved runbook and access record signed off by the records, security and IT owners.
What happens to chat history from before you switch the feature on
Compliance exports do not include posts sent before the feature was enabled. Anything written in channels and direct messages before the switch-on date sits outside the export job, so a regulator or litigation request that reaches back past that date will find nothing in the archive connector. Before go-live, the compliance owner needs to decide whether the organization requires that earlier history at all. The answer depends on the records schedule, any open matters and the retention periods already in force, and it should be written down with the business owner who signs off the archive design.
If past history is required, a self-hosted deployment can export it with the export command line tool rather than relying on the scheduled compliance export. That is a separate piece of work with its own run, its own output location and its own review. Confirm with your Mattermost support channel or the official documentation which command options cover historical ranges, how the output is structured for your archiving target, and whether the run can be repeated without duplicating records. Do not assume the output matches the scheduled export format until you have tested it.
Check the historical output against a sample of messages you already know exist. Pick a small set across public channels, private channels, direct messages, a thread with replies, a message with a file attachment and a message that was later edited or deleted. Confirm that each one appears, that the timestamps, sender, channel membership and attachments match what users see in the client, and that the scope matches the date range and teams you asked for. Record any gaps, such as messages from users who have since been deactivated, and decide whether they are acceptable before the archive is treated as complete.
Record two values in the evidence file as part of the go-live sign-off: the enablement date, meaning the date the compliance export feature was switched on for the deployment, and the earliest timestamp present in the exported data, whether from the scheduled export or the historical run. Together these two values state exactly where the archive begins. An auditor or litigator who asks what the archive covers can then be answered from the record rather than from memory. Store the sample test results and the sign-off next to those two values so the reasoning travels with the data.
What Mattermost exports do not cover
A Mattermost compliance export gives you message, file and direct message records for archiving. It does not settle the program-level obligations that regulators and assessors apply to the wider environment. Each area below needs its own owner, evidence and assessment, and each is often assumed to be covered by the export.
PCI DSS scope and assessment
The export does not decide whether your Mattermost server sits inside the cardholder data environment. Scope depends on whether the server stores, processes or transmits cardholder data or sensitive authentication data, or could affect the security of that environment. A Report on Compliance from a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance, is a separate deliverable that your acquirer or payment brands determine. Settle the scope decision before any channel or export receives card data.
DORA register and contract terms
The export holds no view of your ICT contract inventory. DORA Article 28(3) requires a register of information covering all contractual arrangements for ICT services. Article 28(8) requires documented, tested exit strategies for services that support critical or important functions, and Article 30(2) requires contract terms on service and data processing locations, advance notice of changes and data return on termination. Confirm which of these your organization owns for a self-hosted platform and who holds the support contract.
Swift CSCF independent assessment
The export does not satisfy the Swift Customer Security Controls Framework. The framework has 32 controls, 26 mandatory and 6 advisory, and Swift users must have their controls independently assessed and attest compliance annually in the KYC-SA application. Mattermost is one component in that environment. Ask your assessor which controls depend on the messaging server, how its hardening and administrator access are documented, and who signs the attestation.
SEC ITGC evidence
The export produces message records, not IT general control evidence. SEC Release 33-8810 names program development, program changes, computer operations and access to programs and data as example ITGC areas for SOX Section 404 assessments. A Mattermost deployment needs change records for server upgrades and plugin installs, operations records, and periodic reviews of who can administer the server and read exports. Confirm these with your external auditor before relying on the export as a control.
FTC Safeguards multi-factor authentication
The export does not enforce or evidence multi-factor authentication. The FTC Safeguards Rule in 16 CFR 314.4(c)(5) requires MFA for any individual accessing any information system unless the Qualified Individual approves an equivalent control in writing. For Mattermost, the answer depends on your identity configuration, including whether SSO through SAML or OIDC is the only login path. Confirm which login paths exist and obtain the Qualified Individual's written decision for any exception.
Retention and legal hold policy
The export moves records out of Mattermost but does not decide how long they are kept or when deletion must stop. Retention schedules, custom retention policies and legal holds that suspend deletion for named users are a separate control. They are covered in the sibling topic on Mattermost data retention and legal hold for GDPR and litigation. Confirm that retention rules and holds are in place before exports become your archive of record.
Questions buyers ask before hiring help with Mattermost compliance exports
Does Mattermost compliance export require an Enterprise plan?
Yes. Mattermost compliance exports are available on the Enterprise and Enterprise Advanced plans, so confirm the plan level with Mattermost before you budget. Mattermost sells its plans as prepaid annual subscriptions priced by seat licenses, and its pricing page lists no public figures, so buyers request a quote. Ask Mattermost to confirm in writing whether your seat count, user growth or archive connector choice changes the tier you need. DeployOpen's quote covers the implementation services and follows the written scope of your engagement. The Mattermost license is bought from Mattermost.
What does a Mattermost compliance export project cost and what drives it?
Cost components: the Mattermost subscription (paid to Mattermost and recurring each year), the archive provider's subscription and onboarding (paid to that vendor), and the implementation work (quoted by DeployOpen from a written scope). The services usually cover file store sizing and access design, export configuration, historical export effort, and evidence preparation. Costs rise with the number of users and channels, the volume of files, the length of history you need to backfill, the number of access designs, and the number of approval steps your organization requires. Storage is recurring. Ask every quote to separate one-time and recurring lines, and to state the data volume it assumes.
How long does Mattermost compliance export setup take?
Duration depends on scope and on the archive provider's onboarding, which often sets the critical path. DeployOpen agrees timelines in the written scope before work starts, so ask for the phases and the dependencies it assumes. Work takes longer when the historical backlog is large, when storage or identity access is still unresolved, when archive contract terms need legal review, or when approvals wait on one busy person. Ask your archive provider in writing for its onboarding steps, test environment availability and typical lead time. Then schedule the backfill window around your change calendar and freeze periods.
Does Mattermost export messages sent before compliance was enabled?
No. Mattermost compliance exports do not include posts sent before the feature was enabled. Self-hosted deployments can export past history with the export command line tool, so backfilling is a separate task from switching the feature on. Decide the history window before you enable the feature, because posts removed by retention policies may no longer exist when you export. Check whether any legal hold or retention rule should run first, and record which date range each export covers. Test the backfill on a copy of your data so the evidence trail shows what was exported, when, and by whom.
Where does a self-hosted Mattermost write compliance export files?
Self-hosted exports are written to the exports subdirectory of your configured file store, which is either local storage or S3. You can also send exports to an alternate file store target using S3 presigned URLs. Engineers should check access controls on that path, encryption at rest, backup coverage, and who can read or delete export files. In a high availability cluster, file storage must be shared, on Amazon S3, an S3-compatible service or NAS mounted on every node, because local file system storage will not work correctly and risks corrupting files. For presigned URLs, confirm link expiry and access logging with your platform team before go-live.
What must our team provide for a Mattermost archiving engagement?
Your team must provide archive vendor contract details, identity and file store access, and a named owner who approves designs and signs off on evidence. The contract matters because the archive provider defines onboarding steps and will hold the records you are protecting. If your organization is in scope of DORA, the ICT services contract must state where services are provided and data is processed, and it must cover data return on termination (Article 30(2)). Also record the arrangement in your register of information (Article 28(3)). Provide Mattermost admin accounts, file store credentials or an IAM role design, and access to your identity provider for SSO and user sync. Name one approver who can decide quickly on retention, access and evidence questions.
Can an internal team set up Mattermost compliance exports alone?
An internal team can do much of this alone if it already administers Mattermost, runs object storage and identity services, and has someone who understands records obligations. The parts that need the most care are export access design, the historical backfill, and evidence. Control A.5.33 in ISO/IEC 27001:2022 asks that records be protected from loss, destruction, falsification, unauthorized access and unauthorized release, so your export store needs documented controls and tested recovery. Internal teams often find archive onboarding and contract review slower than the technical setup. Weigh your team's capacity for these tasks against the scope you would need to hand over, and ask for a written scope to compare.
Will DeployOpen certify that our Mattermost archive meets regulations?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and decide whether a framework is satisfied. Ask for an evidence list in your written scope, such as configuration records, access reviews, export logs and runbooks, and ask your auditor which items they need in what format. Confirm with your legal or regulatory team which obligations apply to your archive and retention design. Checking delivered items against the agreed scope and the auditor's request list helps prevent gaps at assessment time.
How DeployOpen scopes and delivers Mattermost compliance export work
DeployOpen plans Mattermost compliance export and eDiscovery archiving as a fixed-scope piece of work inside infrastructure you control. We start from your retention obligations, the archive target you already run, and the history that must be recovered, then build and document the export path so your records and compliance teams can verify it.
How we scope
- Confirm which archive target you use, such as Smarsh Vantage, Global Relay, Proofpoint or CSV, and who receives the exports.
- Map which plan level, file store and deployment type your Mattermost server needs before export is enabled.
- Record in the written scope whether pre-enablement history must be exported with the export command line tool.
How we build
- Configure the export job and confirm where exports are written, either the exports subdirectory of local or S3 file storage or an alternate target using S3 presigned URLs.
- Test that direct messages, file uploads, plugin posts and bot or webhook posts reach the archive with channel member history.
- Set access controls on the export location so that exported records are protected from unauthorized access and release.
How we hand over
- Deliver runbooks covering export schedules, file store paths, archive target settings and the steps for recovering history.
- Document the history gap, listing the date the feature was enabled and what the export command line tool can backfill.
- Provide evidence of test exports and access settings so your compliance team can map them to its own control records.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, including checks after Mattermost monthly releases.
- Ask in the quote which components recur, such as support hours, upgrade work and archive target changes, and which are one-time.
