Data Protection isn’t just about privacy: an object lesson…

Yesterday the Irish Times had an interesting article on the Department for Children and Youth Affairs’ new National Childcare Scheme, which is likely to cause some trouble for the department. It turns out that the department has gone live with a system to apply for the National Childcare Scheme that only works with the Public Services Card (or more accurately, the “MyGovID” database that the PSC is a physical token for.)  If you have a PSC, you can apply for the scheme in October. If you don’t have a PSC, you won’t be able to apply for the scheme until next January, and your benefit won’t be backdated.

Aside from the problems of launching a system requiring the PSC just after the Data Protection Commission stated that the department doesn’t have a legal basis to do so, this situation illustrates some of the things about Data Protection that I try to highlight when I give GDPR training.  Three things about Data Protection that I try to emphasize are that:

• GDPR is Human Rights based legislation with firm foundation in the European Charter for Fundamental Rights, requiring that when we process data about people we make sure that we don’t violate their rights. We may think of GDPR and Data Protection in general as “privacy law” because when we process information about people privacy (Article 8) is the first right to be violated, but we need to consider all of the rights.  That’s 50 articles worth of rights to consider.
• GDPR is risk-based legislation, but the risk management we are doing is risks to the fundamental human rights of the people whose data we are processing. Reducing risk to the organization processing personal data is a benefit of doing it right, but from the perspective of GDPR, it’s an incidental benefit.
• If you do Data Protection Impact Assessments right, they are a useful planning and design tool that will help save you a lot of heartache and money later on.

A DPIA is not just mandatory in some cases, it’s also a very good idea in general.

So, let’s say you are designing a new application system for a benefit scheme everybody in the country is eligible for. You want to use an online Single View of Customer identity confirmation system like MyGovID that isn’t compulsory to have, and not everyone has.  (Let’s call this SVC.)

Introducing this new application system would require a Data Protection Impact Assessment under GDPR.  (It’s a new process that involves large scale processing of personal data, possibly special category personal data, and has a significant effect on individuals). This isn’t just a bureaucratic exercise, it’s trying to figure out what possible issues you might have with compliance, and what possible negative effects your new thing might have on the people you’re processing information on.

It’s very important that when you conduct a DPIA you remember that Data Protection is not only about privacy, it’s about upholding people’s fundamental rights.  Privacy is important; you want the confidentiality of the information preserved, and you need to make sure that you aren’t excessively intrusive in your eligibility assessment. But, aside from your Article 7 right to Privacy and your Article 8 right to protection of your personal data, there are another 48 or so rights listed in the European Charter for Fundamental Rights, and some of them are very relevant – for instance, the right to equal treatment under the law (Article 20), the rights of the child (Article 24), rights to social security and social assistance (Article 34), and the right to good administration (Article 41).  With these in mind, you need to make sure that everyone who is eligible for the benefit scheme can apply for it and will be treated fairly and equally.

When building your system, you have some major considerations:

• You don’t have a lawful basis to require people are enrolled in and use the SVC, and if you only let people with the SVC apply, you are not treating people equally under the law. (This is something that the RSA must have considered last year, when they dropped the requirement to provide a PSC to get a driver’s license, after ploughing something like 2 million euro into the project.)
• Forcing people who don’t have a SVC to use a slower manual application process could be seen as unequal treatment. It’s definitely unequal treatment if you don’t make the manual application available until several months after the online application and refuse to backdate the benefit.

A DPIA might break this down into a few different types of risk:

• Compliance risk: Demanding the SVC might be unlawful processing under GDPR. Excessive processing (depending on what is going on at the back end of the SVC . . . what’s actually in that “Single View of Customer” database?)
• Risk to the organization: Fines, bad publicity, loss of customer trust, exposure to lawsuits, being forced to scrap and redesign the system.
• Risk to the fundamental rights of the person: Violation of rights to equal treatment, loss of benefit to which the data subject is eligible, excessive processing . . .

The first two types of risk are important to the organization, but data protection is most focused on the rights of the data subject, how what you do affects the people whose information you are processing.  However, all three types of risk point out that you might want to make sure that a SVC isn’t a fundamental requirement for the functioning of your application system.

But that’s not all: Mandatory but not Compulsory digital applications are also a problem

But there are further considerations:

If you design a system meant to process all people, you need to make sure you can treat all people equally. That includes people who are not digitally literate or do not have computers. You can have parallel digital application systems with more than one way of confirming the identity of applicants, but you need to make sure old-fashioned paper applications are also available and applicants aren’t penalized for using them. Not everyone can afford a computer, and requiring online application, either with or without the SVC identification, will create extra hardship for the people in most need. Processing paper applications manually may take longer and be more expensive to process than mostly automated digital application, but a government body should not externalize that cost to the people it is supposed to serve.

As with the problems inherent in making the PSC “mandatory but not compulsory”, this is an issue that has been a matter of public discussion in the past year.   In 2018, the UN’s Special Rapporteur for Poverty gave a scathing report of the United Kingdom’s “digital by default” strategy for Universal credit, saying, “ despite official protestations to the contrary, ‘digital by default’ is really much closer to digital only.” The report pointed out that defaulting to digital presented a barrier that obstructed access to entitlements, and that the greatest harm went to those most in need. Additionally, many of the “cost savings” of going digital weren’t actual savings but rather externalized the costs, pushing work and the costs not just to the people in need, but to already stretched library services whose budgets were slashed.

So… how do you make sure that your new system treats people equally and doesn’t exacerbate injustice?  Can you design your new system in a way that doesn’t open you up to lawsuits? These are big things to think about when planning and designing a system, and it’s extremely advantageous to use a DPIA to help you grapple with these issues early on in the planning and design stages rather than treating your impact assessment as a bureaucratic tick box exercise for someone to fill out just before you go live with the thing you already built.