By now, you’ve probably heard of the EU’s General Data Protection Regulation (GDPR). It’s a hugely far-reaching set of regulations, but here’s a very abridged background:

• If your business holds data for EU citizens or residents – regardless of where your business is located – you’re affected
• When EU folks are handing over their data, you need to be exceedingly clear what you’re going to do with it
• You have to get their permissions, and they can revoke those permissions at any time
• You have to be able to export their data for them, and erase it as well
• Enforcement with financial penalties starts May 25th
• The penalties are no joke: up to 4% of your company’s worldwide revenue or €20 million, whichever is higher (not lower)

GroupBy is a community thing, but it’s owned by Brent Ozar Unlimited, so I wanted to be really transparent about how everything works. As I worked through the issues, I also figured I’d share ’em with you here, dear reader, so you could understand how it affects your blog, your local user group, and even PASS.org. I figure it’s my job to set a good data steward example for y’all.

First: here’s how attendee registration used to work.

Lemme show how big it is just by explaining one simple task: registering an attendee. The home page of GroupBy.org used to have a form on it that let you register for the next event, and register for the email list to be notified whenever we updated stuff:

See the form at the bottom right? That was built with Gravity Forms, a WordPress plugin that would:

• Save your data in the WordPress database
• Subscribe you to a MailChimp.com mailing list (thankfully, early on, I’d decided to use an isolated MailChimp account for GroupBy with no leakage to BrentOzar.com’s mailing list – it cost me more, but boy, was that worth it.)
• Send a message to Zapier.com, which would register you at GoToWebinar.com

That’s a lot of moving data. Sure, it made registration really easy on your part – but achieving GDPR compliance with all that was going to be expensive and time-consuming. I just couldn’t dedicate that much of my personal time for a community project.

Here’s how attendee registration works now.

So here’s what we switched to instead:

Now, we’ve got two buttons:

• Register to Attend for Free – takes you to a signup form hosted at GoToWebinar.com.
• Subscribe to Email Updates – takes you to a signup form hosted at MailChimp complete with very specific legalese from MailChimp.

The process isn’t as seamless, and I would guess we’ll probably lose some signups to a lower conversion rate. That’s okay. It’s worth it to accomplish the short term goal: for us to personally hold zero attendee data. By taking out Gravity Forms, it means we just don’t need to see your data. (We also deleted all past data from past attendees.)

We still have access to GoToWebinar & MailChimp data, though, because we can log into those sites and export attendee emails. (We don’t – but we could, and I’m not happy about that.)

Here’s how I hope attendee registration will work in the future.

Down the road, I’d love to go even further and not be able to access the attendee data. We simply don’t need it. We’re not in the business of making money off that data or analyzing the metrics – it’s just a community effort on my part to give back.

For the live webcast, that means running it as a registration-free live broadcast embedded in the web site. GoToWebinar doesn’t offer that possibility (yet.) If GoToWebinar doesn’t up their game soon, we’ll probably have to take a slight hit on product quality and switch to something like YouTube or Twitch where we truly don’t know anything about the attendees.

For the mailing list, that means switching to a product that doesn’t allow us to access the emails directly. I haven’t seen a product like that yet – it’s counterintuitive to what most email marketing folks want to use, obviously.

We’ve made a lot of progress.

GroupBy.org is built with WordPress, an open source content management system. WordPress has an incredible plugin ecosystem that makes a lot of things easy – but unfortunately, some of these pose GDPR compliance challenges:

• Google Analytics and/or Jetpack for visitor tracking – on all of our sites, I simply removed both of those because we don’t need visitor tracking.
• WPengine Content Performance – plugin that tells authors how popular their posts are. I originally implemented this to make it easier for MVPs to track their visitor stats, but removed it here. They can look at the public view counts on the YouTube channel instead.
• Multi Rating Pro – plugin to let readers rate sessions. Unfortunately it tracked user data, so out it goes.
• WP-Polls – plugin for session voting. It uses cookies to track whether you’ve voted or not, so we’ll need to solve that problem before the next round of voting.
• Users without posts or comments – originally, we configured GroupBy so that as people registered, they also got a GroupBy.org account to make it easier for them to submit sessions later. I deleted around 2K of those folks – no sense in holding risky data. I’d highly recommend the free plugin Delete Spam Users, which made it really simple to delete users without posts or comments.
• MailChimp handling of existing subscribers – technically, when we email existing subscribers about upcoming events, we’re marketing to them. That means we need to get their explicit permission for that. We’ve enabled MailChimp’s new GDPR compliance plumbing, and we’re sending re-confirmation emails to all existing subscribers to update their preferences or else they’ll be removed from the mailing list. Better safe than sorry.

But we still have work to do.

The session-submission process is the first big challenge. When someone submits a session, they:

• Create an account here (which includes their email address)
• Publish a blog post (the sessions are blog posts under the covers)
• Get emails as people comment on their session abstract
• Get emails from me when their session is up for voting, and accepted or declined

That session submission process is built atop WordPress’s authorship infrastructure. Thankfully, WordPress’s very vibrant ecosystem means that WordPress is working on GDPR compliance as we speak. I’ve been watching their roadmap and the GDPR fixes coming in 4.9.6, and here are some of the updates I’m most excited about:

• Let registered users self-service deletion or anonymization of their private data – looks like they’ll request it, and a confirmation will be sent to their email, then they’ll have to click that to verify their identity
• Auto-delete users after a period of time
• Consent logging framework – to permanently track when a user has given (or revoked) consent for different uses of their data
• New privacy policy settings

The more I’ve watched the WordPress folks at work, the more I’ve learned about additional GDPR issues I never would have considered – for example, embeds. Take a typical session like Bert Wagner’s on SQL injection – it has two embedded files at the start of the post, a podcast and a SlideShare slide deck. Well, those embedded files are served by other companies (Libsyn and SlideShare), and that means they can get information about you just from you visiting the site, and they can put cookies on your computer.

Sure, I can go through our past presentations, pull any unneeded embeds (and just link to them instead), but a malicious presenter could submit a new session with an embed in it, and if we didn’t catch it, it would present a GDPR compliance risk to anybody who visited the page with the embed.

Ugh. I’ll be busy this month. Thank God the WordPress community makes a lot of this easier.