Matrix for GDPR message retention and erasure

The retention decision starts with the Synapse setting, because Synapse can only enforce a period through its message retention policies. The stable option is a server-wide default policy with max_lifetime, which follows MSC1763. Per-room m.room.retention policies are experimental, so a team that relies on them should test their behavior on the Synapse version it runs and confirm the result in writing before using them for personal data. Without either policy, no message in a room is ever purged, so the platform team must treat a missing setting as an open compliance gap. Manage the policy as a configuration item with a named owner, a review date and a test on a staging homeserver before each change reaches production.

Expiry and deletion are separate steps, and the difference matters for erasure evidence. Once an event passes its limit, Synapse stops serving it to clients, but the event stays in the database until the next purge job runs. Set the purge interval deliberately, write it into the operations runbook, and check the database after a test run to confirm that rows for an expired test message are actually removed, not only hidden. Database backups are outside the purge job, so the backup retention period needs its own rule. Ask the platform team to record the purge interval, the backup retention period and who approves changes to either.

The policy also has scope limits that the reader must plan around. Synapse never deletes the last message in a room, so a quiet room can keep one old message past its period. State events are outside retention, so membership, room names, topics and power levels remain after the messages they relate to have expired. Membership events can carry display names and avatars, which are personal data. Map which state events contain personal data in your deployment, and ask the DPO whether those items need a separate justification or a different handling approach. Confirm each of these behaviors on your Synapse version with a test room before you describe them to data subjects or auditors.

The retention period is a decision for the DPO and the business owner of each room type, not for the platform team alone. Article 5(1)(e) of the GDPR limits storage of personal data to no longer than is necessary for the purpose of the processing. Article 25(2) requires that, by default, only the personal data necessary for each specific purpose is processed, including with respect to the period of storage. For each room type or message category, record the purpose, the chosen period, the legal basis for keeping data that long and the reason for the value. Review that record whenever the purpose changes. It becomes part of your evidence file, which independent assessors and supervisory authorities will examine.

A retention purge or an erase flag only acts on the homeserver where it runs. In a federated room, each event is copied to every homeserver that has members in that room, so a purge on your Synapse server does not delete the copies held by remote servers. The erase flag set through the deactivate account admin API has a similar limit. Messages sent by an erased user stay visible to users who were in the room when they were sent and are hidden from users who join later. That behavior is correct for your server, but it says nothing about what a remote server keeps. Treat your local settings as the scope of your own control, and plan for the remote copies separately.

The main technical lever is federation_domain_whitelist. It restricts federation to the domains you list, so events are only exchanged with those servers, and an empty list disables federation entirely. The Synapse documentation also recommends firewalling the federation listener, which uses port 8448 by default. An alternative is to serve federation through delegation on port 443. Decide which approach fits your network, then confirm in a test environment that a server outside the list cannot fetch events or join your rooms. Record the result, because it is evidence that your configuration does what your policy says.

Article 17(2) of the GDPR adds a legal dimension. Where the controller has made personal data public, it must take reasonable steps, including technical measures, to inform other controllers processing that data that erasure of links, copies or replications has been requested. Whether messages in a private federated room count as made public is a question of fact and law, and the answer affects what your organization must do. Whether a remote homeserver operator is another controller for this purpose is also open. Ask counsel to set out how remote copies should be handled, what notice, if any, is expected, and what records you must keep when a request arrives.

The decision that matters most comes before any erasure request. Your organization should decide which remote servers it is willing to federate with, record that list and the reasons for it, and review it on a set schedule. Consider which rooms really need federation and which can stay local to your homeserver. Those choices determine how many remote copies can exist for personal data. Once a request arrives, you will have limited ability to change them. Confirm the list, the room design and the counsel guidance with your data protection officer, and make sure the people who handle requests know where the decisions are documented.

Whether a Synapse deployment involves a third-country transfer depends less on where the homeserver sits than on which servers receive the events. When a room includes users whose accounts live on servers in other countries, messages leave your infrastructure through federation and are delivered to those remote homeservers. Chapter V of the GDPR governs transfers of personal data to third countries, and Article 44 applies the same conditions to onward transfers, so what a remote server forwards onward is part of the analysis. The first task is to map which remote servers receive room traffic, and in which countries, before deciding whether any transfer mechanism is needed.

Hosting the homeserver in an EU data center does not settle the question. EDPB Guidelines 05/2021 (version 2.0) treat remote access from a third country as a transfer, even where data is only displayed on a screen for support or administration, and treat storage in a cloud outside the EEA as a transfer. The federation path and the hosting location are therefore separate questions, and each needs its own record. Confirm with counsel whether traffic to any remote server qualifies as a transfer, and whether operators or support staff located outside the EEA can open message content, including through administration consoles or screen sharing.

Where a cloud provider or support engineer needs access to message content in the clear, EDPB Recommendations 01/2020 (version 2.0) become relevant. Those recommendations state that where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. For a homeserver, the database and media stores hold message content, so your team should document who can read those stores, from which countries, and who holds the encryption keys. Example 12 of the same guidelines states that an EU processor subject to third-country law with extraterritorial effect does not by that fact alone create a transfer. Complying with a third-country authority request would be one, so that exposure should be assessed before you engage such a processor.

The exposure is concrete for some providers. The US CLOUD Act provision at 18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, regardless of whether that data is inside or outside the United States. Article 48 of the GDPR allows a third-country court judgment or administrative decision requiring disclosure to be recognized or enforced only where it rests on an international agreement in force with the Union or a Member State. Whether either point affects your provider depends on its corporate structure, contracts and sub-processors, which counsel should review before any contract is signed. Ask the provider for its written position on government access requests and how it notifies customers.