Summary of current state of GDPR compliance

We ( are in the process of GDPR-proofing our operations. As others pointed out, the danger is not the authorities but the Abmahnanwälte, who are suing e.g. small personal blogs for lacking the legally-mandated two distinct ways of contacting the author, using images without licensing information and similar things, and who are collecting several hundred or several thousand Euros each time in settlement fees from these tiny one-person businesses. They will make a killing under the GDPR.

Here’s our understanding of what our Discourse instance should provide in order to be safe from such litigation. Can a team member please indicate which of these already exists or is in the works, so that we don’t invest time re-inventing the wheel or parallel-coding something that is already in the works?

  • Delete all - since social media posts have been ruled to be ‘personal data’, forum posts are likely to be interpreted to be the same, and fines are likely until someone goes to court over this. I heard that some forums wish to try their luck with a CC licensing of posts and anonymising only. This is not an option for us because in Germany, ownership can never be legally transferred, so the way the CC licensing works out is that you always retain the right to delete your own posts, without however gaining the right to force people who copied/quoted your posts to delete the quote. So the option to mass-delete one’s posts must exist. We wish to offer users the choice to either anonymise or truly delete their posts upon leaving our community and we hope that most will decide to anonymise. Ideally, deletion should have a safety hatch, e.g. being required to type ‘DELETE’ as in Mailchimp, or posts being marked as for-deletion in the database but only effectively being removed after one week without remorse.

  • Export all - JSON export of all rows of all tables that include the user’s ID. This seems simple to do, see e.g. . The legal purpose is twofold: a) to show the user what information is collected on them and b) allow them to import the data elsewhere, i.e. truly make them the owner of their data.

  • Auditable data processing - Companies are required to be able to provide, if requested, a log of their staff’s data processing actions. This may be covered by Discourse’s Moderator Log. However, does it cover everything? E.g. if an admin changes someone’s forum name for them, is that logged somewhere? It should be, at least internally, in order to be able to comply.

  • Consent management - We have taken note that companies now cannot sign people up to all their newsletters through their Terms and Conditions but have to get separate consent for each newsletter, detailing its purpose. Hence Discourse would be legally on much safer ground if, beyond the consent to the Terms and Conditions, the Send Me Forum Emails checkbox could be present already on the registration page.

  • Log deleted users - The GDPR states that users’ personal data must be deleted even from backups. As that is very difficult to do, short of the cryptographic solution that found, we shall simply keep no backups beyond the 30 days that we have to delete users. However, if someone deleted their account 2 days ago and we are forced to restore a backup from 3 days ago, that person’s data will be back in our system and won’t be getting removed within 30 days. Hence, the list of user IDs of deleted accounts should be stored somewhere (outside the database) in order to make it possible to delete them again while restoring a backup.

  • Removing personal data from logs, since logs are another form of storage. Should be as easy as adjusting the filter_parameter_logging.rb:

I have read some of the GDPR discussions about what is or isn’t necessary, what Discourse should or shouldn’t do, and I don’t want this post to become another one of those. Our lawyer’s interpretation of the law is this, so my only question is in how far Discourse does the listed things, or will do these things, and in how far we’ll have to code it on our own, through API or possibly a plugin for those organisations whose lawyers have the same understanding of what should be done.


I think it’s probably best if you do your own analysis of the degree to which Discourse satisfies your lawyer’s interpretation of the legal environment in which you operate. Any misunderstanding of your requirements, or a lack of specificity in the description or response, could potentially cause problems for you. If you do decide, through your review, that Discourse is lacking in any aspect, you can make a concrete change proposal (preferably including UI mockups where appropriate) for discussion before you (or anyone else) spends time on implementation.


Thank you, of course we shall do our own due diligence as well, but rather than time-consuming reverse-engineering what Discourse currently does and guessing at what is in the works, it would be good to get a summary on these points from one of the coders, before committing our forces to help with the rest (either as part of the official next release or as a plugin or as our own modification, whichever way your team thinks best). Some of these questions should be straightforward to answer, e.g. regarding the log of admin changes to profiles, or letting users delete their posts, or which tables may be missing but relevant to the current JSON export feature.

Best wishes,


It would be good to know what the Discourse team is putting on their roadmap for GDPR compliance - in particular the consent screen (which is something we’ll need to show all present and future members, I think).

May 25th is very close now.


I disagree. This is what one of the leading ICT legal experts in the Netherlands says about it:

it does not apply when the processing (ie the publication) is necessary for the exercise of the fundamental right of freedom of expression (article 17 paragraph 3 GDPR). ). Thus, a forum administrator can in principle prevent the removal of messages.

Does the Right to be Forgotten apply to forum posts?
(AVG is the Dutch term for GDPR) (original here)