User Tools

Site Tools


Sidebar

projects:gdpr:start

General Data Protection Regulation

Introduction

The GDPR came into force on 25-May-2018. I feel the matter is of sufficient importance to warrant its own project, so here it is. There's quite a lot to do, certainly from my own point of view, so I'm attempting to clarify some thoughts here.

Please feel free to add your own bits and pieces here, or feed them back to me.

Activity

This section will be updated as the project progresses.

Here are the next steps for the project:

  • Allow time for reading and collect feedback.
  • Produce policy documents and make them available.
  • Add privacy related text to printed material:
    • Membership application forms.
    • Event booking forms.
    • Competition entry forms.
  • Add privacy related text and/or links to web pages:
    • Joining up page.
    • Event booking pages.
    • Competition entry pages.
    • Contact form.
    • Comments form.
    • Login page (including cookies).
  • Design and document all procedures, including:
    • Personal data copy requests.
    • Data correction requests.
    • Data removal requests.
    • Data breach procedures.
  • Implement tools to handle data procedures.
  • Carry out security audits for all stored data.
  • Find out what else is needed.

Here is the associated task list. The assigned person in the “who” column is usually the one driving the task. It does not imply they are the one doing all the work.

TaskStatusWhoDescription
Collect feedback.DoneKMGather ideas and other feedback about the project in general.
Produce policy documents.DoneVLProduce the privacy policy documents.
Review policy documents.DoneAllReview and refine the documents until we're all happy with them.
Publish policy documents.DoneKMMake policy publicly available through various channels.
Update membership forms.Not startedCFAdd privacy related text.
Update festival booking forms.Not startedCF
Update Wentworth booking forms.Not startedCH
Update open competition forms.Not startedPF
Update members' competition forms.Not startedCH
Update joining up page.Not startedKMAdd privacy related text/links.
Update festival booking page.Not startedKM
Update open competition page.Not startedKM
Update contact form.DoneKM
Update comments form.DoneKM
Update login page.DoneKMAdd privacy related text/links, including cookies.
Design & document procedures.Not startedAllMay need research. What are the legal implications?
Implement tools for procedures.Not started?e.g. automation for data copy/removal requests. Unlikely this will get done, given the pending website move.
Security audit.Not startedAllCheck all documents and databases for privacy and security. At home and in the cloud. Report all findings, including both failures and successes.
Further research.Not started?Carry out research into what else we need to do to become GDPR compliant. For example: Do we need to record our data processing activities? Do we need to appoint data protection officer(s)? What things, if any, are we exempt from as a registered charity?

Privacy & Personal Data Documents

Perhaps the most important components, at least at the start, are the privacy & personal data documents we'll need. This will apply not just to the website, but to all parts of the association where we collect and store information on groups and individuals.

The documents will, at least, help us to know what we should be doing, even if we're not yet doing it.

Documents Availability

The documents should be available to anyone who wants to read them, so where should we keep the master copies? We can make them available in a number of places, e.g.

  • To read on the website (done).
  • To download as documents from the website (done).
  • To receive as documents via email attachments.
  • To receive through the post.
  • Other? Braille versions?

We must be careful about how we manage the documents. They must be consistent across all methods of delivery. We don't want all sorts of different versions floating about.

Cookies

From an internet article on cookies and GDPR…

When cookies can identify an individual via their device, it is considered personal data.

What this means:

  • Implied consent is no longer sufficient. Consent must be given through a clear affirmative action, such as clicking an opt-in box or choosing settings or preferences on a settings menu. Simply visiting a site doesn't count as consent.
  • “By using this site, you accept cookies” messages are also not sufficient for the same reasons. If there is no genuine and free choice, then there is no valid consent. You must make it possible to both accept or reject cookies. This means:
  • It must be as easy to withdraw consent as it is to give it. If organisations want to tell people to block cookies if they don't give their consent, they must make them accept cookies first.
  • Sites will need to provide an opt-out option. Even after getting valid consent, sites must give people the option to change their mind. If you ask for consent through opt-in boxes in a settings menu, users must always be able to return to that menu to adjust their preferences.

Analysis of Cookies on the NAWG Website

Here's a table of all cookies that are currently used on the NAWG website.

CookieValueDescriptionNotes
wordpress_{hash}Login name followed by encrypted credentials.Allows users to be logged in and gain access to restricted content.Can identify a person. This cookie is not set for visitors who remain logged out.
wordpress_test_cookieWP+Cookie+checkUsed to test whether login cookies are permitted by the user's browsing device.Does not identify a person.
PHPSESSIDHashed session identifier.Used by the mini-tales competition software to see if a user is logged in.Unclear whether this can identify a person. The use of this cookie will be removed in the next release of the website, as the competition software never reached the stage of logins being used for fully online submissions, which are actually done via email.
DYNSRVServer identifier.This is set by the hosting company's web server. It is used for load balancing and server performance.Does not identify a person.

Experiments reveal the following:

  • The contact form does not use cookies, despite what was said in an earlier version of the cookie policy document.
  • The commenting system does not use cookies, despite what was said in an earlier version of the cookie policy document.

Here's the original text.

Cookies are also used in the following circumstances:

When you submit a comment or reply to another comment, data that identify you personally are saved in a cookie. This is done for convenience, so that you don't have to re-enter the information when you make subsequent comments.

When you send us a message using the contact form, data that identify you personally are saved in a cookie. This is done for convenience, so that you don't have to re-enter the information when you send subsequent messages.

This has turned out not to be true for the current website, but may become true for the new website. For this reason, the above text is still worth considering when the cookie policy document is revised.

Conclusion: the only place where users need to be made aware of cookies and our policy, is when they attempt to log in, since those particular cookies can identify them. All other cookies fall under the essential operations category and do not constitute personal data.

Password Protection

On the subject of password protection…

  • Sensitive documents need individually password protecting. Your general computer/operating system login password is not sufficient, because the device might be stolen and the storage drive could be removed and read without a password, unless you've encrypted the drive.
  • We should use strong passwords, not weak ones. Crackers are far too good these days.
  • All documents, databases, etc. should have different passwords.
  • How will we manage the passwords? e.g. what happens when I get a knock on the head, forget all my passwords, and others need them during my recuperation period?

Data Breach Procedure

I strongly suspect we'll need one. Nobody wants a breach, but they can happen. At the moment, I have very little idea about what this might involve.

Tools & Resources

There are a number of tools available, that might help our efforts towards GDPR compliance. For example:

  • Mailchimp:
    • ?? – Henry?
  • WordPress (available since the upgrade to version 4.9.6, all need reviewing and testing before use. At first glance, it looks like a rush job and I don't trust it):
    • Data request handling.
    • Removal request handling.

By themselves, the tools will not be sufficient. There's all sorts of other things that will need doing, mostly manually. Please see the task list in the activity section.

projects/gdpr/start.txt · Last modified: 2018/07/31 11:13 by wicked