GDPR and Genealogy: The living and the dead

Unless you’ve been on a trip to Mars it can’t have escaped your attention that the European Union General Data Protection Regulation (GDPR) came into force on 25 May 2018.

A family tree is an unlikely place for GDPR issues to surface, since it’s mostly about dead people to whom GDPR doesn’t apply.  But every tree has some live ones and family historians who host their own genealogy websites need to think about the implications of GDPR and “what lies beneath.”  There are aspects of GDPR that go beyond cookie consent and privacy statements.

The Genealogist’s GDPR Dilemma

In the past few months we have all seen a flood of requests to consent to cookies and accept site privacy policies.  Wherever you go, the now-familiar prompts pop up, and we may have become blasé about accepting them. 

Each of these is asking us to approve the information that is associated with our online account on that site.  And so it should.  But if we’re running a family history site we have information that goes deeper than that because every living individual also has an entry on the family tree.  My tree has hundreds of them and 99% do not have an account on the server because their details were entered by the family historians.  The amount of information varies, but usually has a minimum of full name, date of birth and the names and dates of birth of the parents – just the kind of information that could be used in identity theft for example.

Doesn’t GDPR only apply to companies?

It’s true that GDPR was conceived primarily to control the corporate excesses we have seen lately, with massive breaches leading to the leaking of millions of  records.  Because corporations were the main target most of the available literature focuses on them too.  This creates the false impression that we family historians are exempt.  The regulation is quite clear – there is only one exemption for personal use, and it is strictly limited:

2. This Regulation does not apply to the processing of personal data: ... (c) by a natural person in the course of a purely personal or household activity


That means you can collect information about yourself or members of your household – effectively so you can run your day-to-day life. That doesn’t include collecting information on your extended family.

This is why genealogy is a GDPR edge case. The drafters did not have family trees in mind as a typical use case. They were driven by the excesses of corporations who abuse our data but, as so often happens, the law of unintended consequences led to us being caught in the net.

Does GDPR apply to family trees?

Fig 1 shows the three GDPR touchpoints that apply to family trees and the access limitations that should apply to anonymous and registered users.

Fig 1: GDPR in family trees

A and B are the standard touchpoints for every website.  Anonymous users need to consent to cookies.  Registered users have an account, and that imposes data privacy rights and the full range of GDPR protections.  So far so normal.

Group C is the contentious one, and there is little information available on this niche use.  Comparisons can be made to other sites that hold personal information without the subject’s knowledge or consent – credit agencies for example. I believe GDPR applies and here’s why.

The regulation says:

What constitutes personal data?

The GDPR applies to ‘personal data’ meaning any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organisations collect information about people.

I don’t see any wiggle room there.  Personal information is exactly what we hold in our family trees.

May I collect information on living family members?

The regulation provides a number of lawful reasons for collecting personal data and there’s one that seems to be apply to family trees:

Processing shall be lawful only if and to the extent that at least one of the following ... f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

Art. 6 GDPR Lawfulness of processing

I believe creating a family tree is a legitimate interest of a family member.  The phrase shown in bold is a concern but I think that is addressed by another article in the regulation:

Where the processing for a purpose other than that for which the personal data have been collected is not based on the data subject’s consent ... the controller shall, in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data are initially collected, take into account, inter alia: ... (b) the context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller;

Art. 6 GDPR Lawfulness of processing

So that would seem to provide the permission we need. It’s a grey area though and demonstrates that genealogy is definitely a GDPR edge case.

What do the big sites do?

Here’s the relevant section from Ancestry UK’s Privacy Policy as at 30 April 2018:

It’s absurdly brief.  The responsibility is yours and the information is voluntarily offered, meaning that there is no contractual basis for you adding the information (there’s a different approach to information held under contracts.)  For me that raises a red flag for people who use the big sites – they are unaware of their obligations as a controller.  And even if they are aware, how would they meet them? 

Your GDPR roles

By hosting your own site on your own hardware or using a third party, you have absolute responsibility for data protection.

If you run your site on a hosted service you also need to make sure they have policies and procedures in place to protect the integrity of the data – but you should be doing that regardless of GDPR.  If the hosting company is based in the EU they are more likely to be GDPR compliant but that’s not a given.  If they are outside the EU they may well not be.

That may all sound academic, but if your site is attacked and there is a data breach, the issue might come back to bite you.  Collecting your relatives’ personal information to create a family tree is one thing – leaking it accidentally is another matter entirely.  If that should occur there may be sanctions.  On you.  From your family if not from the EU.

Who cares?

We’re small fry, so why bother?

Our family history sites aren’t quite what the lawmakers had in mind when they drafted the regulation and probably not high on the enforcement list either.  But the law applies to everyone and if you can protect your site with little or no effort, why wouldn’t you?

I’m based in the US, and untouchable

That’s a précised version of a reply from a Facebook group member and it’s technically correct – unless you have a presence in the EU, enforcement is a challenge.  Nor will you be high on the enforcement list (see previous item.)  But if you can comply at little or no effort, why wouldn’t you?  As another responder said, “Why do you need a law to do the right thing?”  Why would you risk falling out with family members?

If your tree contains people, especially minors, you have a moral, family duty to care for their data regardless of the protection laws in your jurisdiction.

Less obvious personal identifiers


It’s worth taking another look at what constitutes personal data:

The GDPR applies to ‘personal data’ meaning any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organisations collect information about people.

How that applies to photos is currently untested.  I’ve heard some fee-conscious lawyers have suggested that a distinctive watch, or a mole pattern on an arm that’s in shot, are personal identifiers.  That sounds like scaremongering; but a captioned photo of a living person that says something like “<Person’s name> <Date> 18th Birthday – at home” that was taken on a GPS enabled camera will provide some juicy information for identity thieves.  And there may be even more useful information in the EXIF data if you have tagged your images.

For all photos of living people, you must make sure that:

a) captions are “safe”

b) any GPS coordinates and other personal identifiers are stripped from the EXIF data.  There are many tools that will do this for you

In TNG, as long as the media files are associated with an individual’s record, setting the living flag will suppress that media to everyone who is not a registered user.


Do you store scanned copies of birth certificates?  That’s not only a personal identifier it’s a document that would be very useful to an identity thief.  If you’re lucky, your application will suppress these documents when the living flag is set.  If not, it may be safer to take those records offline.

If your web application’s ability to suppress documents that relate to living people depends on the media being linked to that person, you need a site policy that no unlinked personal media is allowed.


GDPR has a specific Article that deals with genetic information.  You can read the complete clause here but this is the relevant part:

1. Processing of personal data revealing racial or ethnic origin ... and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person ... shall be prohibited.

Paragraph 1 shall not apply if one of the following applies:
(a) the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject; ...

(j) processing is necessary for ... historical research purposes ... in accordance with Article 89(1) based on Union or Member State law which shall be proportionate to the aim pursued, respect the essence of the right to data protection and provide for suitable and specific measures to safeguard the fundamental rights and the interests of the data subject.

GDPR Article 9 - Processing of special categories of personal data

I am not sure that Clause J is applicable.  DNA results may be a useful addition but we can document our family trees without them, therefore this is not a necessary use.

So we’re left with clause (a) – explicit consent.  The need for explicit consent for DNA data overrides the earlier clauses that allow a family member to capture personal information for a legitimate interest.

In order to store a person’s DNA results on a family history site you must obtain the individual’s explicit consent.  You cannot depend on the general consent given by their acceptance of the privacy policy.

Actions To Take

Review Application Settings

Check out what cookies are generated by your chosen application.  There may be some simple quick wins to reduce the cookie load.  For example, TNG has the ability to add a Share button to its pages.  But this feature will add several third party cookies.  On balance I decided that the limited benefit of a share button did not justify the effort to research and publish details of those cookies, so I disabled the feature.  If I need to share, it’s easy to copy the page’s URL from the address bar.

Restrict Access

Suppress details of living people

If your family tree software supports it, turn off access to living people.  In TNG, there is a living flag that can be set on an individual’s record and you can set it to default on or off for every newly entered record.  When set to living the system will not display the person’s record to anonymous visitors.

While it’s not a GDPR requirement, TNG has a private flag which can be applied to any person.  It allows you to make the record of a deceased person invisible to anonymous visitors.  This is useful for suppressing details of recently deceased people especially in sensitive situations such as the death of an infant.

Make editors aware of their obligations

You need to ensure that anyone who has editor access to the record is aware of the need to use the living flag correctly.

Monitor correct use of the living flag

Given that the vast majority of the people you add to a family tree are dead, setting the TNG default setting for the living flag to off will allow the majority of added records to be correctly flagged but this runs the risk of failing to set the flag correctly on newly added living people, and exposing a record that you shouldn’t.

You could default the flag to on, but then you may suppress records of deceased relatives.  On balance this is a safer route.

These are only default settings.  Registered users can change the flag manually.  So whichever way you default the flag you need to do regular checks to make sure that all living people are correctly flagged.  In TNG a simple report will allow you to do this.

Control the addition of registered users. 

You need to control the creation of registered user accounts, because, in TNG, registered users will be able to see details of living people.  I use a simple rule:

Not in the tree, no account.

Users can self register on my site but every account has to be manually activated by me.  I don’t allow anyone else to add users.

Privacy policy

First, you need one.  Second, users need to be prompted to accept it.  Your application should allow you to do this.  If it doesn’t, it’s not GDPR compliant and it’s time to look for an alternative.

TNG has GDPR capabilities.  It has a default but editable Privacy Policy and a mechanism for gaining and recording consent from users.  It satisfies most of the GDPR requirements but doesn’t work for me because I use a WordPress front end on my family history site, and I need to provide GDPR capabilities on those pages too.  Once integrated with TNG, the WordPress wrapper on the TNG pages extends the WordPress GDPR functionality to them.

Writing a privacy policy

You could clone a policy from another site.  You could clone TNG’s.  You could clone mine. The WordPress GDPR plugin that I use has a policy generator that you can use to cherry pick the clauses.  All these sources can give you a good start but they’re only a start, they are not a total solution. However you start, there are some key principles to follow. 

1. It must apply to the particular circumstances that apply to your site.  A generic policy will not do.  Your hosting platform, it’s country of location, the apps you use, the WordPress plugins you enable, the TNG mods you use and the basic app settings you make – all of these will influence the content of your privacy policy.  One size does not fit all.

2. It must be concise, transparent, intelligible and easily accessible

3. It should be written in clear and plain language.

4. It must sufficiently inform the data subject:

  1. Who is collecting the data?
  2. What data is being collected?
  3. What is the legal basis for processing the data?
  4. Will the data be shared with any third parties?
  5. How will the information be used?
  6. How long will the data be stored for?
  7. What rights does the data subject have?
  8. How can the data subject raise a complaint?

 5. It must address the needs of all groups in Fig 1.

Gain Consent

Scenarios A & B in fig 1 require you to gain a registered user’s consent to store cookies and the personal information that you require to run their account.

Typically this consent is gained using a pop up toolbar.  TNG has that capability.  WordPress has a number of GDPR plugins with various capabilities.  I chose  GDPR by Trew Knowledge because it provides all the standard consents and:

  1. Alerts you to apply for re-consent when you change your privacy policy
  2. It has out-of-the-box solutions to the requirements of the next section.

Provide user feedback mechanisms

GDPR requires you to have mechanisms in place to allow users to exercise their rights. The four that apply to a family history site are:

  • Request Data
  • Request Corrections
  • Request Deletions
  • General Complaints

Full information about the data subjects rights can be found in Chapter 3 but these functions are core to GDPR so cannot be ignored.

I am not aware of TNG’s capability in this regard, but the GDPR plugin from Trew Knowledge has out-of-the-box capabilities to handle them, which is the main reason I chose it.  It was easy to setup and it has functions that provide:

  • Configurable  front-end pages for each of the four topics above
  • Shortcodes to allow you to insert links to the pages, in your privacy policy
  • A back-end system to manage submissions
  • Data breach notifications
  • Automated email notifications to the admin and the enquirer

A formal system may seem overkill for a site where all the enquirers are family members but:

  • It’s a legal requirement
  • The plugin makes it easy to do, so why not do it?

Feedback about living people

The GDPR plugin is good, but even it can’t handle the living people issue, so my privacy policy guides people to the contact form for that specific purpose.

Keep it current

Setting up GDPR capabilities is not a one-time thing – you need to keep them up to date.  For example, changes to the applications may affect the privacy policy. Perhaps you might start to collect DNA, in which case you need to reflect this in the policy and figure out a way to collect and store the explicit consents that are required.  Or you turn on a feature such as the TNG Share button that spawns a set of third party cookies, so you have to supply details of those cookies.

GDPR is not “fire and forget.”  You must keep it current


A family tree would be diminished if details of living people were not included but their presence is not incompatible with GDPR compliance.

Allowing people to discover, correct and delete their personal data is clearly essential but the spotlight would really fall on you if a data breach occurred.  Scrutiny will be much easier to bear if you can demonstrate that you have acted in good faith and done as much as could reasonably be expected of you.

Use the available tools, apply some common sense rules and GDPR compliance is easy to achieve.  Why wouldn’t you protect valuable information about your kith and kin?  You do it in your own digital life don’t you?



This article is based on my interpretations of GDPR.  Feel free to use the content to inform your decisions on what to do, but the responsibility for GDPR compliance on your site is yours, and must be based on your site’s particular circumstances. I cannot accept any responsibility for your reliance on my opinion.

  1. A very helpful and informative article Paul. Thank you.

    I know some people are of the view that personal and family sites are exempt from the regulations. That is incorrect.

    The regulations are concerned with the protection of privacy and personal data. Regardless of who is holding or using that data.

    Sure, the ‘targets’ were the big companies which have acquired a reputation for being cavalier with information we may have given, not fully understanding how it may later be used. But small companies, and yes, personal sites are using very similar information about us all daily. We would all be shocked if we were able to see all that is known about us just through the web sites we visit.

    It is unlikely in the short term that our small sites will be the target of action to enforce the regulations. But if someone takes objection to information you make available, or that you hold about them, then they now have the option to take legal action. That entails stress and costs none of us need, particularly when they can easily be avoided.

  2. Well said. Couldn’t agree more. That’s the heart of the issue.

  3. This decoding of the legal issues was necessary, Paul. Thank you for that.
    It is true that our TNGs are amateur sites, and as such not really concerned with GDPR, but we do collect, handle and publish sensitive personal data, and about living people.

    Despite this new legislation, I am not going to change much my way of communicating through this media. Because the GDPR is not for us French a revolution, but a very progressive evolution of the privacy protection that we have implemented for decades. The main real revolution is its extraterritoriality when it involves citizens of the European Union.

    In application of our already long-standing legislation on the protection of personal data, I was compelled almost 10 years ago to make my genealogical research private, at the request of 3 persons of my family. Although data less than 100 years old were already private, in accordance with French legislation. So I reserved my work for the members of my site, deleted my trees online on the large generic genealogy sites and consequently, limited the possibilities of exchange and knowledge sharing.

    My family’s protesters didn’t do their research work conscientiously: their personal data still exist on the Internet without me being the editor, because other family members have personal genealogy sites and online trees on generic sites. People need to be aware that their privacy is their responsibility.

    Let us hope that one of the effects of the GDPR will be this public awareness about privacy. For the time being, this regulation has above all highlighted the fundamental differences between the cultures of the various countries and the resulting legislations. In France, DNA research is formally prohibited, except for medical or judicial reasons, as are racial or religious statistics. These strict legal prohibitions are so integrated into our mores that they are taboo.

    Many non-European sites already bar access to European residents so as not to risk violating extra-territorial regulations and the penalties that could result. Does this GDPR go too far and risk accentuating these misunderstandings between our cultures and reproducing a Babel Tower?

    • Well said Katryne

      I think the extra-territoriality issue is perhaps one of the more contentious issues. I have had already had pushback from a couple of US Facebook users whose attitude is that they will act only when forced to by the US Congress.

      I would add the following to the list of new features that GDPR brings

      1. The rights to view, and request correction and deletion (the right to be forgotten)

      2. The harmonisation of Data Privacy across the EU. (The UK too has had decades of Data Privacy regulation.)

  4. Over many years, my now elderly cousin researched our family tree and related ones in great detail, and assembled & displayed the results (in non-standard format) on his public website, right down to names & dates of birth of his youngest relatives.

    When he became incapable of continuing this work, I offered to “rescue” the whole (directly from the internet) and install it similarly on my own public website, which I did. But I am now realizing that rather than bringing the picture up to date as was my aim, I should instead be suppressing all public evidence of it, for data-protection reasons!

    Am I right, and if so, how can I do this, or at least demonstrate that I’ve made some attempt to do it, given that nothing ever really disappears from the internet?

  5. I am in the process of making a website concerning my own family tree. It seems that publishing names of living people would be a bad idea. But could I for example just write that somebody had 2 boys and a girl, without publishing their names? And could I put their years of birth? Or would this make them identifiable? Thanks.

    • You could omit names and just put a year of birth. But, are you writing the “tree” code yourself? The software I use (TNG) gets round this problem by enabling you to set a Living flag on a person. You can even default on to make sure you don’t miss it. With that flag set, the person is only visible to users who are logged in, and the only people who have a login are family members. Problem solved. The software is very inexpensive. I strongly recommend it to you.

      • I may well do as you described and make the full details only available to those with logins. But to clarify, simply putting a gender and year of birth (will obviously show parents etc as well) couldn’t possibly be in breach of GDPR? I just wonder as it’s easily enough information to identify the living person even without naming them.

  6. Hi Paul,
    Thank you.
    I am writing my own family tree code , use space of a web hosting provider . The access in app is limited to members of family (who previously registered a username with password).
    This is like a family tree on a paper in my desk drawer and when a member of my family is in my office and wants to take a look at it he can but anybody else can not.
    But all the data are stored on a hosting space in fact.
    In this case, does the law (GDPR) apply to my activity?

    • Yes, GDPR applies to you. You are storing details of living people. But why are you writing your own code? That just increases the risk because your app may be vulnerable?

  7. What do you mean by the terms ‘ consent of the people’? – 11817480

  8. Informed Consent Law covers the legal … not know that a rare complication can lead to severe injury or death and may decide against the treatment if he or she did …

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>