Skip to main content

GDPR: why 'purpose' is a great starting point

Originally published on LinkedIn, June 2017.

“Purpose” is the best starting point for GDPR compliance because it unlocks every downstream requirement — from your Article 30 records to your data flows and lawful basis decisions. Organisations that skip this step and jump straight to “processing activities” often find themselves mapping the wrong things at the wrong level of detail.

Why “processing activities” alone is not enough #

Article 30 of the GDPR requires organisations to maintain records of processing activities, making it essential to understand what that term actually means in practice. In my view, the list of processing activities should form the index of your organisation’s data inventory and map, perhaps categorised by functional area.

From my own experience, organisations struggle to identify their processing activities in relation to personal data if they do not already have some existing structure around how they govern and manage personal data. A common mistake is substituting “processing activities” with “business processes” — in some cases they can be one and the same, but often they are not. In my mind, it all starts with “purpose”.

What happens when you ask the right question #

I recently facilitated a series of data mapping workshops in an organisation moving from one department to another. The marketing department were perplexed when I began to ask about their purposes of processing. “We need the data to do marketing” was the first response. Eventually we dug down a level or two and were able to be not just granular about specific purposes but also granular about the data items per purpose and so on. In this particular workshop, walking through customer journeys aided the team’s understanding of “purposes”.

Here is an important and often overlooked point when booking meetings or workshops: allow sufficient time up front to provide education and training in how to work with a particular concept. To help participants see the connections between “purpose”, “processing activities”, “data subjects”, “data items”, and “lawfulness of processing”, I produced the diagram above — which uses the elephant as an analogy of the typical GDPR challenge organisations are facing.

Diagram showing the connections between purpose, processing activities, data subjects, data items, and lawful basis in a GDPR compliance programme

Purpose examples: travel #

For a travel company, the purposes for processing personal data about a customer could include:

  • To make a travel booking
  • Enter a competition or promotion
  • Complete a survey
  • Report a problem with the web site
  • Record details of transactions and the fulfilment of bookings and purchases
  • Internal research purposes
  • Improve customer service
  • Report aggregate information to advertisers

Purpose examples: HR #

From an HR perspective, the purposes for processing personal data could include:

  • To assess an individual’s qualifications and suitability for a position
  • To administer HR processes such as performance reviews and disciplinary action
  • For remuneration, payroll, and pension administration
  • To establish a contact point in the event of an emergency at work
  • To manage an employee’s interactions with the facilities and services offered by the organisation, such as physical access
  • To establish an employee’s training and development requirements

What comes next: data flow mapping #

Once you have identified your purposes and the processing activities that follow from them, the next step is to understand and map how personal data flows for each activity across the organisation. My earlier article describing a structured and visual approach to data flow mapping explains an approach that enables a common understanding among a wide group of stakeholders, tests the GDPR principles, and identifies the key tasks in your compliance project.

Frequently Asked Questions #

What does “purpose” mean under the GDPR? In GDPR terms, “purpose” refers to the specific reason an organisation collects and uses personal data. Article 5(1)(b) requires that data be collected for specified, explicit, and legitimate purposes. Defining purpose with precision is the foundation for building an accurate record of processing activities under Article 30 and for selecting an appropriate lawful basis.

What is the difference between a processing activity and a business process? A business process describes how work gets done in an organisation; a processing activity describes specifically how and why personal data is used within that work. They can overlap — but often they do not. Conflating the two leads to incomplete or inaccurate data mapping and gaps in your Article 30 records.

How should I structure my records of processing activities? Use your list of purposes as the index, grouped by functional area - Marketing, HR, Finance, and so on. For each purpose, identify the relevant data subjects, data items, lawful basis, data flows, and retention periods. Walking through customer journeys is a practical technique for surfacing purposes that might otherwise be missed in a workshop setting.


If you found this useful, the Purpose and Means newsletter covers GDPR, data governance, and privacy strategy — fortnightly, in plain language.

Purpose and Means works with organisations on data protection strategy, governance, and compliance - going beyond the legal text to focus on how things actually get done. If you’d like to discuss what this means for your organisation, book a call or explore our services.

Author
Tim Clements
Tim Clements is Business Owner of Purpose and Means, a data protection and GRC consultancy based in Copenhagen, operating globally. He helps data protection and GRC leaders simplify complexity into actionable strategies, providing tools, training, and support to engage and influence across the organisation. Tim is a Chartered Fellow of the BCS (British Computer Society).

Browse by Topic

access controls accountability accountability frameworks ai act ai ethics ai governance ai infrastructure sovereignty ai literacy ai regulation article 12 article 13 article 22 article 25 article 28 article 30 article 32 article 35 article 46 article 5 article 6 article 7 audit and assessment automated decision-making awareness awareness campaigns behaviour change beyond legal board level board reporting case law change management chief people officer cloud infrastructure compliance monitoring consent cookie compliance cross-border transfers customer success dark patterns data accuracy data breach notification data flows data mapping data minimisation data processing agreements data protection data protection by design data protection culture data protection day data protection hero data protection leader data quality data residency data retention data science data sovereignty data subject rights datatilsynet deceptive design design thinking direct marketing dora dpia education employee data employee engagement enterprise architecture eprivacy esg executive communication external legal counsel finance and banking gdpr gdpr at 10 generative ai governance grc healthcare history horizon scanning hr and data protection hr and employment incident response information security intellectual property internal communications international transfers lawful basis leadership lego serious play machine learning marketing nis2 passwords privacy by design privacy culture privacy policy product management profiling public sector purpose limitation quantum computing records of processing regulatory guidance risk management risk reduction ropa sales security software development special category data standard contractual clauses strategic planning sub-processors supply chain sustainability system design third-party risk training training design transparency trend radar ux design vendor management visual communication weak signals workshop facilitation

Related Posts