Why the Tory app data breach could happen to anyone

June 2024

Shakespeare wrote (I hope I remembered this correctly from ‘A’ level English), ‘When sorrows come, they come not single spies but in battalions.’ He could’ve been writing about the UK Conservative Party which, let’s be honest, hasn’t been having a great time recently.

The Telegraph is reporting the party suffered it’s second data breach in a month. An error with an app led to the personal information of leading Conservative politicians – some in high government office – being available to all app users.

Launched in April, the ‘Share2Win’ app was designed as a quick and easy way for activists to share party content online. However, a design fault meant users could sign up to the app using just an email address. Then, in just a few clicks, they were able to access the names, postcodes and telephone numbers of all other registrants.

This follows another recent Tory Party email blunder in May, where all recipients could see each other’s details. Email data breaches.

In the heat of a General Election, some might put these errors down to ‘yet more Tory incompetence’. I’d say, to quote another famous piece of writing, ‘He that is without sin among you, let him first cast a stone’! There are plenty of examples where other organisations have failed to take appropriate steps to make sure privacy and security are baked into their app’s architecture. And this lack of oversight extends beyond apps to webforms, online portals and more. It’s a depressingly common, and easily avoided.

In April, a Housing Associate was reprimanded by the ICO after launching an online customer portal which allowed users to access documents (revealing personal data) they shouldn’t have been able to see. These related to, of all things, anti social behaviour. In March the ICO issued a reprimand to the London Mayor’s Office after users of a webform could in click on a button and see every other query submitted. And the list goes on. This isn’t a party political issue. It’s a lack of due process and carelessness issue.

It’s easy to see how it happens, especially (such as in a snap election) when there’s a genuine sense of urgency. Some bright spark has a great idea, senior management love it, and demand it’s implemented pronto! Make it happen! Be agile! Be disruptive! (etc).

But there’s a sound reason why the concept of data proteciton by design and by default is embedded into data protection legislation, and it’s really not that difficult to understand. As the name suggests, data protection by design means baking data protection into business practices from the outset; considering the core data protection principles such as data minimisation and purpose limitation as well as integrity & confidentiality. Crucially, it means not taking short-cuts when it comes to security measures.

GDPR may have it’s critics, but this element is just common sense. Something most people would get onboard with. A clear and approved procedure for new systems, services and products which covers data protection and security is not a ‘nice to have’ – it’s a ‘must have’. This can go a long way to protect individuals and mitigate the risk of unwelcome headlines further down the line, when an avoidable breach puts your customers’, clients’ or employees’ data at risk.

Should we conduct a DPIA?

A clear procedure can also alert those involved to when a Data Protection Impact Assessment is required. A DPIA is mandatory is certain circumstances where activities are higher risk, but even when not strictly required it’s a handy tool for picking up on any data protection risks and agreeing measures to mitigate them from Day One of your project. Many organisations would also want to make sure there’s oversight by their Information Security or IT team, in the form of an Information Security Assessment for any new applications.

Developers, the IT team and anyone else involved need to be armed with the information they need to make sound decisions. Data protection and information security teams need to work together to develop apps (or other new developments) which aren’t going to become a leaky bucket. Building this in from the start actually saves time too.

In all of this, don’t forget your suppliers. If you want to outsource the development of an app to a third-party supplier, you need to check their credentials and make sure you have necessary controller-to-processor contractual arrangements and assessment procedures in place – especially if once the app goes live, the developer’s team still has access to the personal data it collects. Are your contractors subbing work to other third party subcontractors? Do they work overseas? Will these subcontractors have access to personal data?

The good news? There’s good practice out there. I remember a data protection review DPN conducted a few years back. One of the areas we looked at was an app our client developed for students to use. It was a pleasure to see how the app had been built with data protection and security at its heart. We couldn’t fault with the team who designed it – and as such the client didn’t compromise their students, face litigation, look foolish or be summoned to see the Information Commissioner!

In conclusion? Yes, be fast. Innovate! Just remember to build your data protection strategy into the project from Day One.

EU AI Act adopted, and UK approach

March 2024

The EU has adopted the world’s first Artificial Intelligence Act. The legal language has yet to be set in stone but once this has been finalised, and published the Act will be enforced. This is expected in May/June 2024.

It’s worth noting the law will then take effect in stages. There will be six months to ban prohibited AI systems, twelve months to enforce rules against ‘general-purpose’ AI systems, and 36 months to meet requirements for what the law has designated as ‘high risk’ AI systems.

As the EU pushes full steam ahead with AI legislation, the UK is for now sticking to a non-statutory principles-based approach. We take a look at both approaches.

UK approach to AI regulation

The UK Government says it’s keen not to rush in and legislate on AI. It fears specific rules introduced too swiftly could quickly become outdated or ineffective. The Government says it wants to take “a bold and considered approach that is strongly pro-innovation and pro-safety.”

For the time being, key regulators are being asked to take the lead. They’re being given funding to research and upskill, and have been asked to publish plans by the end of April on how they are responding to the risks and opportunities of AI, in their respective domains.

These regulators include the Information Commissioner’s Office (ICO), the Financial Conduct Authority (FCA), the Competitions and Markets Authority (CMA) and the Medicines & Healthcare products Regulatory Agency (MHRA).

The Government has also set up the Digital Regulation Cooperation Forum (DRCF) to “conduct cross-sector risk assessment and monitoring to guard against existing and emerging AI risks”.

Alongside this, a pilot scheme for a new advisory service; the AI and Digital Hub has been launched. This will be run by expert regulators including OfCom, CMA, FCA and ICO.

There’s a recognition advanced General Purpose AI may require binding rules, and the need for international cooperation on AI is also emphasised.  The government’s approach is set out in its response to the consultation on last year’s AI Regulation White Paper

The EU AI Act

In March 2024 the European Union adopted the EU AI Act. Its aim is to ban unacceptable use of artificial intelligence and introduce specific rules for AI systems proportionate to the risk they pose. It will impose extensive requirements on those developing and deploying high-risk AI systems.

It’s likely the Act won’t just govern AI systems operating in the EU, with it’s scope extending to foreign entities which place AI systems on the market or put them into service in the EU.

The Act uses the definition of AI systems proposed by the OECD: An AI system is a machine-based system that infers from the input it receives how to generate outputs such as predictions, content, recommendations, or decisions that can affect physical or virtual environments.

EU AI Act summary

1. Banned applications

There will be prohibited uses of AI which threaten democracy and people’s rights. For example this includes but is not limited to; biometric categorisation systems which use special category data, real-time and remote biometric identification systems (such as facial recognition) and emotion recognition in the workplace and educational institutions.

2. Law enforcement and national security exemptions

There will be a series of safeguards and narrow exemptions allowing for the use of biometric identification systems in publicly accessible spaces for law enforcement purposes. The legislation will not apply to systems which are exclusively used for defence or military applications.

3. Tiered risk-based approach

The requirements organisations will need to meet, will be tiered dependent on the risk. For example;

  • For AI systems classified as high-risk there will be core requirements, such as mandatory fundamental rights impact assessments, registration on a public EU database, data governance, transparency, human oversight and more.
  • General-purpose AI (GPAI) systems, and the GPAI they are based on, will need to adhere to transparency requirements, including having technical documentation, being compliant with EU copyright law and having detailed summaries about the content used for training systems.
  • For Generative AI applications, people will have to be informed when they are interacting with AI, for example a Chatbot.

4. Right to complain

People will have the right to launch complaints about AI systems and receive explanations about decisions based on high-risk AI systems which impact their rights.

5. Higher fines than GDPR

Non-compliance with the rules could lead to fines of up to 35 million Euros or 7% of global annual turnover. This is a notable hike from GPDR which sets a maximum of 4% of annual worldwide turnover.

 

The EU AI Act represents the world’s first comprehensive legislative framework for regulating AI. Could it become a global standard, like GDPR has for data protection? Or will other countries take a non-statutory approach like we’re seeing in the UK, at this stage?

What’s clear is organisations need to take steps now to raise awareness and upskill employees. For example in compliance teams, legal, data protection, security and (by no means least) product development.

Decisions should be made about who needs a greater understanding of AI, how it will be internally regulated and where responsibilities for AI governance rest within the organisation.

Guide to identifying and managing data protection risks

March 2024

Data protection risks come in all shapes, sizes and potential severities. We need to be able to identify the risks associated with our use of personal data, manage them and where necessary put appropriate measures in place to tackle them.

How can we make sure  good risk management practices are embedded in our organisation? In this short guide we cover the key areas to focus on to make sure you’re alert to, and aware of risks.

1. Assign roles and responsibilities

Organisations can’t begin to identify and tackle data risks without clear roles and responsibilities covering personal data. Our people need to know who is accountable and responsible for the personal data we hold and the processing we carry out.

Many organisations apply a ‘three lines of defence’ (3LoD) model for risk management. This model is not only used for data protection, but is also effective for handling many other types of risk a business may face.

  • 1st line: where the leaders of the business functions that process data are appointed as ‘Information Asset Owners’ and they ‘own’ the risks from their function’s data processing activities.
  • 2nd line: Specialists like the DPO, CISO & Legal Counsel support and advise these the 1st line, helping them understand their obligations under data laws, so they can make well informed decisions about how best to tackle any privacy risks. They provide clear procedures for the 1st line to follow.
  • 3rd line: An internal or external audit function provides independent assurance.

3 lines of defence for data protection

For example, risk owners, acting under advice from a Data Protection Officer or Chief Privacy Officer, must make sure appropriate technical and organisational measures are in place to protect the personal data they’re accountable for.

In this model, the second line of defence should never become risk owners. Their role is to provide advice and support to the first line risk owners. They should try to remain independent and not actually make decisions on behalf of their first line colleagues.

2. Decide if you should appoint a DPO

Under the GDPR, a Data Protection Officer’s job is to inform their organisation about  data protection obligations and advise the organisation on risks relating their processing of personal data.

The law tells us you need to appoint a DPO if your organisation is a Controller or Processor and one or more of the following applies:

  • you are a public authority or body (except for courts acting in their judicial capacity); or
  • your core activities require large-scale, regular and systematic monitoring of individuals (for example, online behaviour tracking); or
  • your core activities consist of large-scale processing of special categories of data or data relating to criminal convictions and offences.

In reality, most small organisations are unlikely to fall under the current UK or EU GDPR requirements to appoint a DPO. In fact, many medium-sized business won’t necessarily need a DPO either. Find out more in our DPO myth buster.

3. Conduct data mapping & record keeping

Mapping your data and creating a Record of Processing Activities (RoPA) is widely seen as the best foundation for any successful privacy programme. After all, how can you properly look after people’s data if you don’t have a good handle on what personal data you hold, where it’s located, what purposes it’s used for and how it’s secured?

Even smaller organisations, which may benefit from an exemption from creating a full RoPA, still have basic record keeping responsibilities which should not be overlooked and could still prove very useful. Also see Why is data mapping so crucial?

4. Identify processing risks

Under data protection laws, identifying and mitigating risks to individuals (e.g. employees, customers, patients, clients etc) is paramount.

Risks could materialise in the event of a data breach, failure to fulfil individual privacy rights (such as a Data Subject Access Request), complaints, regulatory scrutiny, compensation demands or even class actions.

We should recognise our service and technology providers, who may handle personal data on our behalf, could be a risk area. For example, they might suffer a data breach and our data could be affected, or they might not adhere to contractual requirements.

It’s good to be mindful about commercial and reputational risks too which can arise from an organisation’s use of personal or non-personal data.

International data transfers are another are where due diligence is required to make sure these transfers are lawful, and if not, recognise that this represents a risk.

Data-driven marketing activities could also be a concern, if these activities are not fully compliant with ePrivacy rules – such as the UK’s Privacy and Electronic Communications Regulations (known as PECR). Even just one single complaint to the ICO could result in a business finding themselves facing a PECR fine and the subsequent reputational damage. GDPR, marketing & cookies guide

Data protection practitioners share tips on identify and assessing risks

5. Risk assessments

In the world of data protection, we have grown used to, or even grown tired of, the requirement to carry out a Data Protection Impact Assessment (DPIA) or a Privacy Impact Assessment (PIA) as it called in some jurisdictions.

Build in a process of assessing whether projects would benefit from a DPIA, or legally require one.  DPIAs are a great way to pinpoint risks and mitigate them early on before they become a bigger problem.

The value of risk assessments in the world of data protection compliance and Quick Guide to DPIAs

6. Issues arising from poor governance or lack of data ownership

In the real world, the three lines of defence model can come under strain. Sometimes those who should take responsibility as risk owners can have slippery shoulders and refuse to take on the risks.

Some processing doesn’t seem to sit conveniently with any one person or team. Things can fall through the cracks when nobody takes responsibility for making key decisions. On these occasions a DPO might come under pressure to take risk ownership themselves. But should they push back?

Strictly speaking, DPOs shouldn’t ‘own’ data risks; their role is to inform and advise risk owners. GDPR tells us; data protection officers, whether or not they are an employee of the controller, should be in a position to perform their duties and tasks in an independent manner” (Recital 97).

The ICO, in line with European (EDPB) guidelines, says; …the DPO cannot hold a position within your organisation that leads him or her to determine the purposes and the means of the processing of personal data. At the same time, the DPO shouldn’t be expected to manage competing objectives that could result in data protection taking a secondary role to business interests.”

So, if the DPO takes ownership of an area of risk, and plays a part in deciding what measures and controls should be put in place, could they may be considered to be ‘determining the means of the processing’? This could lead to a conflict of interest when their role requires them to act independently.

Ultimately, accountability rests with the organisation. It’s the organisation which uses the data, collects the data and runs with it. Not the DPO.

7. Maintain an up-to-date risk register

When you identify a new risk it should be logged and tracked on your Data Risk Register. The ICO expects organisations to: identify and manage information risks in an appropriate risk register, which includes clear links between corporate and departmental risk registers and the risk assessment of information assets.

To do this you’ll need to integrate any outcomes from risk assessments (such as DPIAs) into your project plans, update your risk register(s) and keep these registers under continual review by the DPO or responsible individuals.

Workplace use of facial recognition and fingerprint scanning

February 2024

Just because you can use biometric data, doesn’t mean you should

The use of biometric data is escalating, and recent enforcement action by the UK Information Commissioner’s Office (ICO) concerning its use for workplace monitoring is worth taking note of. We share 12 key considerations if you’re considering using facial recognition, fingerprint scanning or other biometric systems.

In a personal context, many use fingerprint or iris scans to open their smartphones or laptops. In the world of banking facial recognition, voice recognition, fingerprint scans or retina recognition have become commonplace for authentication and security purposes. The UK Border Force is set to trial passport free travel, using facial recognition technology. And increasingly organisations are using biometrics for security or employee monitoring purposes.

Any decision to use biometric systems shouldn’t be taken lightly. If biometric data is being used to identify people, it falls under the definition of Special Category Data under UK GDPR. This means there are specific considerations and requirements which need to be met.

What is biometric data?

Biometric data is also special category data whenever you process it for the purpose of uniquely identifying an individual. To quote the ICO;

Personal information is biometric data if it:

  • relates to someone’s physical, physiological or behavioural characteristics (e.g. the way someone types, a person’s voice, fingerprints, or face);
  • has been processed using specific technologies (e.g. an audio recording of someone talking is analysed with specific software to detect qualities like tone, pitch, accents and inflections); and
  • can uniquely identify (recognise) the person it relates to.

Not all biometric data is classified as ‘special category’ data but it is when you use it, or intend to use it, to uniquely identify someone. It will also be special category data if, for example, you use it to infer other special category data; such as someone’s racial/ethnic origin or information about people’s health.

Special category data requirements

There are key legal requirements under data protection law when processing special category data. In summary, these comprise:

  • Conduct a Data Protection Impact Assessment
  • Identify a lawful basis under Article 6 of GDPR.
  • Identify a separate condition for processing under Article 9. There are ten different conditions to choose from.
  • Your lawful basis and special category condition do not need to be linked.
  • Five of the special category conditions require additional safeguards under the UK’s Data Protection Act 2018 (DPA 2018).
  • In many cases you’ll also need an Appropriate Policy Document in place.

Also see the ICO Special Category Data Guidance.

ICO enforcement action on biometric data use in the workplace

The Regulator has ordered Serco Leisure and a number of associated community leisure trusts to stop using Facial Recognition Technology (FRT) and fingerprint scanning to monitor workers’ attendance. They’ve also ordered the destruction of all biometric data which is not legally required to be retained.

The ICO’s investigation found the biometric data of more than 2,000 employees at 38 leisure centres was being unlawfully processed for the purpose of attendance checks and subsequent payment.

Serco Leisure was unable to demonstrate why it was necessary or proportionate to use FRT and fingerprint scanning for this purpose. The ICO noted there are less intrusive means available, such as ID cards and fobs. Serco Leisure said these methods were open to abuse by employees, but no evidence was produced to support this claim.

Crucially, employees were not proactively offered an alternative to having their faces and fingers scanned. It was presented to employees as a requirement in order to get paid.

Serco Leisure conducted a Data Protection Impact Assessment and a Legitimate Interests Assessment, but these fell short when subject to ICO scrutiny.

Lawful basis

Serco Leisure identified their lawful bases as contractual necessity and legitimate interests. However, the Regulator found the following:

1) While recording attendance times may be necessary to fulfil obligations under employment contracts, it doesn’t follow that the processing of biometric data is necessary to achieve this.

2) Legitimate interests will not apply if a controller can reasonably achieve the same results in another less intrusive way.

Special category condition

Initially Serco Leisure had not identified a condition before implementing biometric systems. It then chose the relevant condition as being for employment, social security and social protection, citing Section 9 of the Working Time Regulations 1998 and the Employment Rights Act 1996.

The ICO found the special category condition chosen did not cover processing to purely meet contractual employment rights or obligations. Serco Leisure also failed to produce a required Appropriate Policy Document.

Read more about this ICO enforcement action.

12 key steps when considering using biometric data

If you’re considering using biometrics systems which will be used to uniquely identify individuals for any purpose, we’d highly recommend taking the following steps:

1. DPIA: Carry out a Data Protection Impact Assessment.

2. Due diligence: Conduct robust due diligence of any provider of biometric systems.

3. Lawful basis: Identify a lawful basis for processing and make sure you meet the requirements of this lawful basis.

4. Special category condition: Identify an appropriate Article 9 condition for processing special category biometric data. The ICO says explicit consent is likely to most appropriate, but other conditions may apply depending on your circumstances.

5. APD: Produce an Appropriate Policy Document where required under DPA 2018.

6. Accuracy: Make sure biometric systems are sufficiently accurate for your purpose. Test and mitigate for biases. For example, bias and inequality may be caused by a lack of diverse data, bugs and inconsistencies in biometric systems.

7. Safeguards: Consider what safeguards will be necessary to mitigate the risk of discrimination, false acceptance and rejection rates.

8. Transparency: Consider how you will be open and upfront about your use of biometric systems. How will you explain this in a clear, concise, and easy to access way? If you are relying on consent, you’ll need to clearly tell people what they’re consenting to, and consent will need to be freely given. Consent: Getting it Right

9. Privacy rights: Assess how people’s rights will apply, and have processes in place to recognise and respond to individual privacy rights requests.

10. Security: Assess what security measures will be needed by your own organisation and by any biometric system provider.

11. Data retention: Assess how long you will need to keep the biometric data. Have robust procedures in place for deleting it when no longer required.

12. Documentation: Keep evidence of everything!

More detail can be found in the ICO Biometric Data Guidance.

The value of risk assessments in the world of data protection compliance

February 2024

In the world of data protection, we have grown used to, or even grown tired of, the requirement to carry out a Data Protection Impact Assessment (DPIA) or a Privacy Impact Assessment (PIA) as it called in some jurisdictions.

What are DPIA and PIA?

They are processes that help assess privacy risks to individuals in the collection, use and disclosure of personal information. They identify privacy risks, improve transparency and promote best practice.

In a report by Trilateral Research & Consulting, commissioned by the ICO in 2013 , it was recommended that “Ensuring the “buy-in” of the most senior people within the organisation is a necessary pre-condition for a successful integration of privacy risks and PIA into the organisation’s existing processes. PIA processes need to be connected with the development of privacy awareness and culture within the company. Companies need to devise effective communication and training strategies to sustain a change in the mindsets of, and in the development of new skills for, project managers. The organisation needs to deliver a clear message to all project managers that the PIA process must be followed and that PIAs are an organisational requirement. Simplicity is the key to achieve full implementation and adoption of internal PIA guidelines and processes.”

The GDPR and guidance from Data Protection Authorities make it clear projects that may require a DPIA include:

  • A new IT system for storing and accessing personal data;
  • Using existing data for a new and unexpected purpose;
  • A new database acquisition
  • Corporate restructuring
  • Monitoring in the workplace

A DPIA will become mandatory in the following cases:

  • Systematic and extensive evaluation of personal aspects of natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects on the individual or similarly affect the individual
  • Processing on a large scale of special categories of data or data relating to criminal offences
  • Systematic monitoring of publicly accessible areas on a large scale

Some data protection authorities have published guidance on how and when to effectively use a DPIA and the DPIA process is best broken down into several distinct phases which are:

  • Identify the need for the project to have a PIA
  • Describe information flows
  • Identify privacy risks
  • Identify privacy solutions
  • Record outcomes and obtain sign-off
  • Integrate outcomes of PIA into project plan

But it is not as simple as set out above.

My experience is that if a DPIA is a risk management tool and is to be considered at the outset of a project, then almost every project or new processing activity needs a pre-DPIA screening process. This at least flags up if a full DPIA is needed and will highlight any areas of risk.

These risks may not only relate to possible infringements of fundamental rights but also to business and reputational risks and infringements of other laws.

Assuming a full DPIA is needed then it is not long in the process before we are assessing the lawful grounds for processing and if we are relying on Legitimate Interests then we need to do a Legitimate Interests Assessment.

Legitimate Interests Assessments (LIAs) – the “balancing test”

An essential part of the concept of Legitimate Interests is the balance between the interests of the Controller and the rights and freedoms of the individual:

‘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.’ GDPR Article 6(1)(f)

If a Controller wishes to rely on Legitimate Interests for processing Personal Data it must carry out an appropriate assessment, called a Legitimate Interests Assessment, or LIA. When carrying out an LIA, the Controller must balance its right to process the Personal Data against the individuals’ data protection rights.

In certain circumstances an LIA may be straight forward. However, under the accountability provisions of the GDPR, the Controller must maintain a written record that it has carried out an LIA and the reasons why it came to the conclusion that the balancing test was met.

International Data Transfer Risk Assessments

In so many projects and data sharing activities we find that personal data is being transferred and the EDPB guidance on risk assessment must be followed and for Controllers in the UK then the ICO guidance applies. There are six steps:

The six steps:

Note that, in order to meet the GDPR’s accountability requirements, each of these steps would need to be documented, and the documentation provided to the supervisory authorities on request.

Step 1: Know your transfers

Understand what data you are transferring outside the EEA and/or UK, including by way of remote access. Perhaps fairly self-evident, but can be challenging when it comes to onward transfers by processors (to sub- processor, or even sub-sub-processors).

Step 2: Identify your transfer tool(s)

Identify what lawful mechanism you are relying on to transfer the data.

Step 3: Assess whether the transfer mechanism is effective in practice

Now we come to the crucial question: in practice, is the transferred personal data afforded a level of protection in the third country that is essentially equivalent to that guaranteed in the EEA/UK?

The EDPB recommends considering multiple aspects of the third country’s legal system, but in particular the rules granting public authorities rights of access to data. Most countries allow for some form of access for law enforcement and national security, and so the assessment should focus on whether those laws are limited to what is necessary and proportionate in a democratic society.

If, after this assessment, you decide your transfer mechanism, ensures an equivalent level of protection, you can stop there. If, however, you decide that the local law does impinge on the protection afforded by your transfer mechanism, you must proceed to Step 4.

Step 4: Adopt supplementary measures

The EDPB separates potential supplementary measures into three categories: technical, contractual, or organisational.

Step 5: Procedural steps if you identified any supplementary measures

This step may lead you to impose regular audits on the importing party.

Step 6: Re-evaluate at appropriate intervals

Monitor developments in the recipient country which could impact your initial assessment. The obligations on the data importer under solutions like the EU Standard Contractual Clauses should help here, as it is required to inform the data exporter of a change of law which impacts its ability to comply with the SCCs.

AI, analytics and new technologies

The EU AI Act is intended to apply to any business that puts AI or uses AI on or in the EU market and so is extra-territorial in its reach. More than that, the AI Act will integrate with and co-exist alongside existing legislation such as the General Data Protection Regulation, the Digital Services Act and the draft Cyber Resilience Act.

The use of new technologies such as smart devices, internet of things and artificial intelligence, coupled with the economic and humanitarian uses of big data analytics, means that there has to be a balance between the acquisition of personal data and the rights of citizens.

Beyond GDPR, PECR, Digital Services Act and so on, assessing your supply chain is more important now than ever, particularly as we rely so much on international suppliers and distributors as well as physical and digital supply chains. We have learned to address issues in the supply chain, such as bribery, competition, modern slavery, and intellectual property; however, more recently we have had to consider geopolitical issues, import and export controls, and other compliance and ethics issues. Now in 2024, we must also consider environmental, sustainability, cyber resilience, digital safety, and accessibility of physical products and digital services that we provide.

Harmful Design in Digital Markets

A position paper on Harmful Design in Digital Markets by the ICO and the CMA is targeted to firms that deploy design practices in digital markets (such as on websites or other online services), as well as product and UX designers that create online interfaces for firms. It provides:

  • an overview of how design choices online can lead to data protection, consumer and competition harms, and the relevant laws regulated by the ICO and CMA that could be infringed by these practices; and
  • practical examples of design practices that are potentially harmful under our respective regimes when they are used to present choices about personal data processing. These practices are “harmful nudges and sludge”, “confirmshaming”, “biased framing”, “bundled consent” and “default settings”.

It now needs us to assess how we manage Data Protection by Design and how we respect consumer choices. Yet another assessment to minimise potential risks!

Nearly 6 years on from the General Data Protection Regulation, we now face a growing list of assessments that we need to carry out, from Legitimate Interest Assessments, Transfer Risk Assessments, Privacy by Design Assessments, Accessibility Assessments, Children’s Code compliance, and now Online Safety, AI and Cyber Resilience….and the list goes on. Have we reached the point where we need an Assessments Handbook that incorporates these various assessments I have outlined and ensure they integrate with each organisations overall risk management policy?

Used appropriately, I find that these assessments really do manage risk and not only protect the rights of individuals but also protect the business from reputational and brand damage. Sometimes, the use of a risk assessment at the start of or even at an early stage of a project, can act as a “Stop” sign and cause the project team and compliance team to say “just because we can doesn’t always mean we should”.

Data protection by design and default – what does that mean really?

January 2024

It’s an obligation in GDPR, but it can still be confusing to get to the heart of what ‘data protection by design and default’ really means, and what you need to do as a result.

It’s often used as a proxy for ‘do a DPIA’ but it’s so much more than that. I’ve seen it described as building or baking in data protection from the start. That’s more accurate but still leaves the question “yes but what does that actually mean?”

What does GDPR say?

It helps to go back to the source, not just article 25 GDPR (1) and (2) but also recital 78. These tell you what the legislators were concerned about, namely implementing the principles. They specifically call out the following.

  • Data minimisation
  • Purpose limitation
  • Retention
  • Wide disclosure / accessibility of the data
  • Transparency
  • Making sure individuals know what’s going on
  • Allowing organisations to set up and improve security measures.

Both the article and the recital mention pseudonymisation as one way to implement the data minimisation principle. It’s an example though, not a mandatory requirement.

The end of recital 78 seems to be directed at those producing software and systems, as well as public tender processes. My take on this is that the legislators were keen to make sure that organisations needing to comply with GDPR didn’t fall at the first hurdle due to a lack of thought for data protection compliance in systems and software. Their expectation is clear for those designing these things for organisations, and I think their hope was that it would lead to software and systems producers having to raise their game to stay competitive.

How to put data protection by design and default into practice

To put this obligation into practice, people often jump to PETs (privacy-enhancing technologies, not Charlie the golden retriever). There have been loads of studies, reports and articles on a range of specific technical measures, too much to go into here. In reality, and in my experience, these more sophisticated methods and third-party software solutions tend to only be available to those with deep pockets and an internal tech team.

The reality for many organisations is to embed DP compliance into processes and policies. When I work with clients on this, I tend to start by looking at how things get done in their organisation.

  • How do you go from “I’ve had a great idea” to “it’s gone live today”?
  • Where are the gatekeepers and / or the decision makers for ideas and projects?
  • How do you manage and record the different steps, phases or tasks needed?
  • How do you identify who needs to be involved, and then involve them?

Once you understand the process and who’s involved, look at what already exists. Many organisations use certain tools to project manage, to assign tasks to people, to report and manage bugs or other issues and so on. Many organisations already have a form or process to suggest ideas, ask for approvals, and to get items on the to do list.

I have found an effective approach is to build on what is already there. No-one will thank you for introducing a new 4-page form on data protection stuff. No-one will fill it in. Where are the points in the processes, or on the forms, or in the tool template to add the DP stuff? Can you add in questions, checklists, templates, approval points and the like?

Examples of data protection by design and default solutions

Speaking of checklists and templates, one of the most effective DP by design ‘solutions’ was where the organisation created a ‘standard build template’ that incorporated key DP principles. So anytime anything needed building or expanding, the build requirements already included things like specific security measures, elements of data minimisation and controls for the end users.

With another organisation there was a two-part solution. One part was for those developing the idea and deciding on the data collection. This involved adapting their project documentation to include key elements from a DPIA and a way to check each data field requested was actually necessary, as well as identify where it might be sensitive or need greater care. The other part was a checklist for those implementing the new thing that set out some core requirements such as the ability for the end user to take certain actions with their data, and what settings or controls had to be off by default. This approach also encouraged better communication between the two groups, as they worked together on which solutions would best implement the core requirements.

Think of the people

Getting to a practical implementation of DP by design and default involves taking a people-centred approach. Both in terms of collaborating with the relevant people internally, as well as thinking about impacts on and risks to the individuals whose personal data you are doing things with.

You also need to consider your organisation’s position on DP compliance. The law might want everyone to do the gold standard, but that’s not the reality we live in. How far you go in implementing DP by design and what your measures look like will be influenced by things like your organisation’s risk appetite, their approach to risk management, any relevant vision or principles they have, or any frameworks or internal committees in place covering compliance, ethics, and so on.

Your colleagues can also be a great asset. Your business development people will have information on what corporate customers are asking for, your end user support people will have intel on what the users complain about. How far do these overlap and where do they conflict?

For example, I have seen the same transparency issue in multiple organisations where both corporate customers and end users want to understand how the product or software works. The corporate customers need to do compliance diligence, and the end users want to know if they can trust the organisation with their data. Producing something for both audiences on how it all works not only helps implement the transparency point of article 25, it also checks if different parts of the organisation have the same understanding of how it works, and flags up discrepancies.

Sometimes, doing something because it leads to a good consumer experience or higher levels of satisfaction gets you to the right place, and can be an easier sell than labelling it a ‘DP compliance requirement’.

Some organisations have the resources to do user research and surveys, and the results of these can be very useful to the DP people. If you can work with and understand the objectives and the pain points of colleagues (such as those managing infrastructure, information security, compliance, risk management, customer support and even the executive team), you’ll be in a good place to see where you slide in your DP stuff, and piggyback on other initiatives.

This is one area of GDPR that takes an outcome-based approach. And the joy that is that it is scalable and adaptable to each situation, and to each organisation’s resources and capabilities. So by focusing on the required outcomes, and putting people at the centre, achieving data protection by design and default can be a lot easier than it first appears.

Our data, tech and the app-ocalypse

January 2024

In 2013, after Edward Snowden leaked thousands of secret files, the Kremlin’s security bureau did something interesting. They swapped computers for manual typewriters. Russian spooks reasoned hard copies were easier to protect than digital files. Furthermore, hackers might be able to infiltrate sensitive systems, but the old-school art of safe-cracking? It seemed to have fallen by the wayside.

As I get older, I’m beginning to think the Kremlin might have been onto something. Why?

Maybe it’s a generational issue. I’m Gen ‘X’. I grew up without mobile phones or the internet, but became familiar with the technology as it developed from the 1990s onwards. I enjoy technology. I respect it. I’m also, however, sceptical in a way many of my Millennial and Gen ‘Z’ colleagues may not be.

For me it boils down to two concerns – trust and over-reliance . Given how there’s now an app for everything, I have to ask – is the App-ocalypse Nigh ? What happens to the increasingly personal and intrusive levels of personal data entered into these ‘everything apps’.

Just because data’s aggregated into zeros and ones, it doesn’t mean it’s ‘tidy’. In fact, I suspect too many digital ‘data warehouses’ resemble the hoarder’s houses you might have seen on daytime TV, with stuff scattered everywhere.

It’s not just apps – the endless requirement to populate online forms is relentless. Now I hear more ‘frictionless facial recognition’ is planned at airports in the UK and elsewhere. And it’s making me uneasy. Technology is wonderful for creating efficiencies and streamlining processes. In my world alone, I see how clever privacy technology solutions ease the burden of data protection compliance.

But is technology always wonderful? Why am I uneasy?

An example – I needed to renew my driving licence. I went on to the Government website and duly entered a great deal of sensitive data. This included my passport number, my mother’s maiden name, my date of birth, my home address and my National Insurance number. This started me thinking… ‘How secure is this platform? What are the Government really doing to prevent my data falling into malicious hands?’

At the other end of the scale, I needed to reschedule a beautician’s appointment (much needed after eating my body weight in chocolate and cheese over Christmas). My call was met by a recorded message. I duly pressed ‘2’ to cancel/change an appointment. I was then informed I must (yes, they did say must) download the app to cancel/change appointments. A look at the app’s privacy information didn’t fill me with confidence, so I rang again, selecting ‘3’ for all other enquiries. After ten minutes of listening to promotions about fantastic rejuvenating treatments, I gave up. What if I prefer not to be forced to register and share my personal details via your app? I’m getting a face treatment, not applying for a pilot’s licence!

At this point, a shout out to the Kennel Club’s customer service. I took out their insurance for my puppy this year. They’re great. I’ve had to call twice, and each time a prompt pick-up from a lovely human. Somewhat of a rarity these days.

I recently read EasyPark Group, the owner of brands like RingGo and Park Mobile, were hacked. Yes, like many others I have RingGo. I was forced to download the app to use a station car park – there was no choice. I also have other parking apps. Oh the joys of standing in the rain in a car park trying to download yet another parking app. Handing over my data to yet another company. Will these companies protect it? What security measures and controls do they have? Did they conduct a DPIA? Was it outsourced to an app developer, possibly outside the UK/EU? Did they do any due diligence?

As well as my fears around data, I also worry for the significant minority disenfranchised by the widescale embrace of what my colleague Simon calls the ‘Mobilical Cord’. It’s so very true – I’m unable to properly function without my smartphone implanted in my paw. I use it to access the internet, my emails, messages, banking and so on. It’s also a crucial part of our company security – to authenticate I am really me.

The 2021 UK Census showed 90% of households had a home computer. 93% had access to a mobile phone. I suspect it’s higher now, but it’s still not everyone. As of 2023, according to research by Statista 98% of 16-24 year olds have a smartphone. However, this drops to 80% for the over 65s. Less tech-savvy and particularly the elderly are being left behind. My mother is 84. I got her a smartphone, but she hates it and doesn’t understand it. Apps? An enigma. She’s also terrified of online scams, knowing how the elderly are disproportionately targeted.

So, now we also face the prospect of passport-free travel. UK Border Force is set to trial an e-gate schemes similar to those rolled out in Dubai and Australia. This negates the need to show a passport, instead using facial recognition technology (FRT).

Phil Douglas, the Director General of Border Force has said “I’d like to see a world of completely frictionless borders where you don’t really need a passport. The technology already exists to support that.” He added: “In the future, you won’t need a passport – you’ll just need biometrics.”

According to the Times the biometric details of British and Irish travellers are already held after being collected in the passport application process. What does Phil Douglas feel about our personal biometrics being potentially harvested by countries with dodgy human rights records?

Too many people will shrug – an end to lengthy queues? Yes please. But who controls my facial map? How will it be used? Will it be shared? How will it be kept secure? Facial recognition tech also raises issues of bias in algorithms, and the potential for mistakes, with serious consequences.

I suspect, one day, there’ll be the kind of disaster one sees in movies, where the Internet collapses for a significant period. What then? I also wonder if, eventually, ambulance-chasers will identify companies using apps to disproportionately harvest data – and playing fast and loose with the safeguards set up to protect us. Will this become the next big Personal Indemnity Insurance (PII) style business opportunity?

What I do know is businesses who put all their eggs in one basket without contingencies, or fail to anticipate risk, are those likeliest to suffer when the app-ocalypse (however it manifests itself) is nigh!

Now, did I mention AI…?

EU AI Act – Quick Factsheet

February 2023

Use of artificial intelligence in the EU to be regulated

In early February European Union member countries unanimously gave a green light to a new Artificial Intelligence Act, following lengthy negotiations and overcoming fears it would stifle European innovation.

The EU AI Act, now needs to be signed-off from EU lawmakers. It’s anticipated it will come into force later this year, with a 36-month implementation period.

The Act aims to ban unacceptable use of artificial intelligence and introduce specific rules for AI systems proportionate to the risk they pose. It will impose extensive requirements on those developing and deploying high-risk AI systems.

It’s likely the Act won’t just govern AI systems operating in the EU, with it’s scope extending to foreign entities which place AI systems on the market or put them into service in the EU.

The definition of AI systems in the Act is one proposed by the OECD: “An AI system is a machine-based system that infers from the input it receives how to generate outputs such as predictions, content, recommendations, or decisions that can affect physical or virtual environments.”

Quick AI Act Factsheet

1. Banned applications

There will be prohibited uses of AI which threaten democracy and people’s rights. For example this includes but is not limited to; biometric categorisation systems which use special category data, real-time and remote biometric identification systems (such as facial recognition) and emotion recognition in the workplace and educational institutions.

2. Law enforcement and national security exemptions

There will be a series of safeguards and narrow exemptions allowing for the use of biometric identification systems in publicly accessible spaces for law enforcement purposes. The legislation will not apply to systems which are exclusively used for defence or military applications.

4. Tiered risk-based approach

The requirements organisations will need to meet, will be tiered dependent on the risk. For example;

  • For AI systems classified as high-risk there will be core requirements, such as mandatory fundamental rights impact assessments, registration on a public EU database, data governance, transparency, human oversight and more.
  • General-purpose AI (GPAI) systems, and the GPAI they are based on, will need to adhere to transparency requirements, including having technical documentation, being compliant with EU copyright law and having detailed summaries about the content used for training systems.
  • For Generative AI applications, people will have to be informed when they are interacting with AI, for example a Chatbot.

5. Right to complain

People will have the right to launch complaints about AI systems and receive explanations about decisions based on high-risk AI systems which impact their rights.

6. Higher fines than GDPR

Non-compliance with the rules could lead to fines of up to 35 million Euros or 7% of global annual turnover. This is a notable hike from GPDR which sets a maximum of 4% of annual worldwide turnover.

 

The EU AI Act represents the World’s first comprehensive legislative framework for regulating AI. It’s anticipated it will become a global standard, like GPDR has for data protection.

What’s clear is organisations need to take steps now to raise awareness and upskill employees. For example in compliance teams, legal, data protection, security and (by no means least) product development.

Decisions should be made about who needs a greater understanding of AI, how it will be regulated and where responsibilities for AI governance rest within the organisation.

As for the UK, some are calling on the Government to include AI in the Data Protection and Digital Information Bill. Conversely, others are warning against hastily-made regulation in this area.