Looking at how IF uses data

I’ve been thinking about GDPR. At IF, we’ve talked to a few clients about what it’ll mean when, next May, new digital rights for citizens across the EU are made real. We think ultimately it could spur innovation, but for now a lot of companies are focusing on compliance. Big organisations are already feeling the pinch, but a lot of smaller companies are hoping they can ignore it. I don’t think they should.

Last month we took a very careful look at how we use data at IF. I wanted to see if capturing it all helped us think differently about how to manage it in the future. I also wanted to make a checklist, to help other small teams do their own audit.

Draw the thing

Our session kicked off with a big question: what data do we have? It wasn’t easy to answer.

Sarah Ian And Georgina Thinking About How If Uses Data
The team draw out www.projectsbyif.com's technical architecture


To begin with, we started to think about what people interact with IF. Who might we have personal data about? How might they encounter us? We had to think about all of our website infrastructure. What logs data? How does that data relate to visitors? Who accesses it?

That stage took a long time, even for a small, privacy-conscious company like IF.

We built our infrastructure with certain aims in mind. Using providers that allowed our kit to be in the UK, for instance, felt important. It also felt important to have as much control as possible over the data we collect. For instance, we host our newsletter software so we deal directly with the data.

But this diagram also flushed out just how much we couldn’t answer right away. Does AWS log any data about the people who view a picture we host on it? If someone unsubscribes from our mailing list, does that delete all of the historic data associated with it? Some of these we could find answers for, others we’re still less certain about.

Write it up

With the drawing to hand, we started writing up how we process the data. We tried to focus on three key questions: What do we have? How do we use it? and How do we store it?

We’ve published all of that. We’ve tried to be as clear as possible about what we get and how we use it. We spent a lot of time making it legible and accurate, while removing as much jargon as we could.

Doing that helped us define some new approaches. We’ve scheduled a regular data audit, in which we do things like delete past Trust & Design events from Eventbrite, and securely archive raw research data. It’s something we plan on improving as time goes on, and we’ll keep the page updated as we do that (along with a changelog).

Our GDPR checklists

If you’re a small company and you publish a newsletter or run an event, it’s likely you also hold a list of email addresses. These are considered personally identifiable information, so you have to think about how that’s affected by the GDPR.

  • Here’s a checklist of things you need to consider, document and communicate to users:
  • How do you collect the email address?
  • Why do you collect the email address?
  • How is the email address used?
  • Who is the email address shared with?
  • What is the impact of collecting the email addresses?
  • Who is responsible in your organisation for the use of these email addresses?
  • How can a subscriber get in touch with that responsible individual?
  • How long is the email address held for?
  • How does a subscriber lodge a complaint, or ask for information held about them (a subject access request)?
  • How does a subscriber withdraw consent for their email address to be used, or stored?

All of this is a crucial part of getting people’s consent to use their information. In general, rules around consent are becoming even more finely grained. It includes things like:

  • Consent needs a positive opt-in – you shouldn’t include pre-ticked boxes
  • There need to be a very clear and specific statement of consent for the data you collect
  • Control of what people have consented to needs to be specific and granular
  • This information should be separate from other terms and conditions
  • The way you communicate this information should be clear and concise – that’s why we spent so much effort making how IF uses data legible to people
  • You need to name any third parties who will rely on the consent
  • You must make it easy for people to withdraw consent and tell them how to do that
  • You also need keep evidence of consent – who, when, how, and what you told people

As a studio, we’re addressing it as openly as we can. Obviously, it’s not just events and newsletters this affects, it also covers things like consent for user research, which Georgina wrote about a few weeks ago. Thinking about the impact in the open has helped other teams improve their approach, and connected us to larger organisations who are working out what GDPR will mean for them.

If you’ve got any thoughts and suggestions, or want to talk to us about your own, get in touch: hello@projectsbyif.com.