Data Protection Foundations
Legal Aspects of Technology Management - NIT Northern Institute of Technology Management, Hamburg · part of my Technology Management MBA · study notes for revision.
The session does not open with a definition. It opens with a company losing more than a billion dollars and then losing the argument with its own insurers. That ordering is deliberate. Data protection and IT security are usually taught as compliance topics, something the legal department worries about after the product is built, and the opening slide is there to break that framing before it forms. The Merck NotPetya case is a story about balance sheets, insurance wording and contract interpretation, and only incidentally about malware.
Once that point has landed, the deck moves to the machinery. It sets out where the rules come from, which is a stack of European and German law rather than a single statute, and then works through the vocabulary that the whole rest of the course depends on: what counts as personal data, what counts as processing, who is the controller and who is merely a processor, who the data subject is, what principles every processing operation has to satisfy, and what makes a processing operation lawful in the first place.
The practical value of this chapter is that it gives you a checklist you can run over any product feature, any vendor contract and any internal process. If you can answer whose data this is, what is being done with it, who decided to do it, why, and on what legal footing, you have already done most of the work. If you cannot answer those five questions, the feature is not ready, whatever the engineering says.
1 · Why this is a commercial problem before it is a legal one
Section titled “1 · Why this is a commercial problem before it is a legal one”The deck makes the business case with three separate pieces of evidence, and they build on each other.
The first is the Merck NotPetya case, set out in full in the Case corner below. The short version: a 2017 malware attack, forty thousand computers, more than 1.4 billion dollars of loss, and insurers who then refused to pay by invoking the hostile or warlike action exclusion in the policy. Both the trial court and the New Jersey Appellate Division rejected that argument. The lesson for a manager is not that the courts will always side with the insured, it is that a cyber loss of that size turns immediately into a dispute about the exact wording of a clause somebody signed years earlier without reading it closely.
The second is the Allianz Risk Barometer 2022, which ranks the most important global business risks for that year:
| Rank | Risk | Share | Examples the deck gives |
|---|---|---|---|
| 1 | Cyber incidents | 44 percent | Cyber crime, IT failure and outage, data breaches, fines and penalties |
| 2 | Business interruption | 42 percent | Including supply chain disruption |
| 3 | Natural catastrophes | 25 percent | Storm, flood, earthquake, wildfire, weather events |
Cyber incidents sit at the top of the list, ahead of business interruption and well ahead of natural catastrophes. Note also what the deck folds into the cyber category: fines and penalties are listed as a species of cyber incident, alongside the technical failures. Regulatory exposure and technical exposure are treated as one risk, because in practice they arrive together.
The third is the regulator’s own toolkit, and this is one place where the course slide is wrong, so these notes follow the Regulation instead. Article 83 sets two tiers of administrative fine, and in each the supervisory authority takes whichever amount is higher. Infringements of the controller’s and processor’s obligations attract up to 10 000 000 euro or 2 percent of total worldwide annual turnover of the preceding financial year (Article 83(4)). Infringements of the basic principles for processing, including the conditions for consent under Articles 5, 6, 7 and 9, and infringements of the data subjects’ rights under Articles 12 to 22, attract up to 20 000 000 euro or 4 percent (Article 83(5)). Article 84 is the provision that leaves any other penalties to national law, requiring them to be effective, proportionate and dissuasive. The slide’s headline of 2 million euro understates the ceiling by an order of magnitude, so quote the article rather than the slide. The slide also points to the public fine database run by the GDPR portal, which is worth browsing to see what regulators actually impose.
Alongside the fine there is a separate private route. Article 82 gives any person who has suffered material or non-material damage from an infringement the right to compensation from the controller or processor. A controller is liable for damage caused by processing that infringes the Regulation; a processor is liable only where it has not complied with obligations aimed specifically at processors, or where it acted outside or contrary to the controller’s lawful instructions. That asymmetry is the first hint of why the controller and processor labels matter so much.
2 · Where the rules come from
Section titled “2 · Where the rules come from”The deck spends several slides on the legal stack, and it is worth taking seriously, because a question in practice is rarely answered by the GDPR alone.
The organising rule the deck states for this stack is that EU law applies uniformly across the member states and takes precedence over national law. So you start from the GDPR, and you go looking in the FDPA only where the GDPR has left a door open.
The German timeline the deck draws is short and worth remembering. From 1994 the old Federal Data Protection Act and the European Data Protection Guideline applied. The GDPR came into effect on 25 May 2016, followed by a two-year implementation phase. On 25 May 2018 the GDPR became directly applicable in the EU member states and the new FDPA came into effect in Germany. Between 2021 and 2024 a follow-up version of the FDPA was drafted but did not pass legislative finalisation on time.
The deck also gives a shortlist of the provisions that carry most of the weight in daily practice, and it is effectively the syllabus for this chapter:
Notice how the German provisions map onto the European ones. FDPA § 22 is the national counterpart to GDPR Article 9 on special categories, and FDPA § 26 governs the employment context, which is where most of a technology manager’s own processing actually happens.
3 · When the GDPR applies at all
Section titled “3 · When the GDPR applies at all”Before asking whether a processing operation is lawful, you have to ask whether the Regulation reaches it. Two articles do that work.
Material scope, Article 2. The Regulation applies to the processing of personal data wholly or partly by automated means, and also to non-automated processing where the data form part of a filing system or are intended to. Article 2(2) then carves out four situations: activity falling outside the scope of Union law, member state activity under the common foreign and security policy chapter of the TEU, processing by a natural person in the course of a purely personal or household activity, and processing by competent authorities for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties including safeguarding against threats to public security.
Territorial scope, Article 3. Three limbs, and the second is the one that catches technology companies. The Regulation applies to processing in the context of the activities of an establishment of a controller or processor in the Union, whether or not the processing itself happens in the Union. It also applies to a controller or processor not established in the Union where the processing relates to data subjects who are in the Union and the activity is either the offering of goods or services to them, irrespective of whether payment is required, or the monitoring of their behaviour as far as that behaviour takes place within the Union. A third limb covers a controller not established in the Union but in a place where member state law applies by virtue of public international law.
The practical reading of Article 3(2) is that a free app with no European office, no European servers and no European revenue is still fully inside the Regulation the moment it has European users whose behaviour it tracks.
4 · Personal data, and what counts as processing
Section titled “4 · Personal data, and what counts as processing”- All information concerning an identified natural person, or concerning an identifiable one, who is called the data subject
- Identifiable means the person can be identified directly or indirectly, in particular by reference to an identifier
- The article names as identifiers a name, an identification number, location data, an online identifier, or one or more factors specific to that person’s physical, physiological, genetic, mental, economic, cultural or social identity
- The deck’s own examples: name, e-mail, online identifier, customer number, telephone number, location data, credit card number
- Any operation or set of operations performed on personal data, whether or not by automated means
- The article’s own list: collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction
- So merely looking at a record is processing, and so is deleting it
- There is no threshold of seriousness and no exception for small volumes
Two consequences follow that beginners consistently get wrong. First, personal data does not mean sensitive data or private data. A customer number is personal data. So is an IP address used as an online identifier. Second, the test is identifiability, not identification: you do not have to know who the person is, it is enough that they could be picked out directly or indirectly.
Article 4 also defines two techniques that sit between personal and non-personal data. Pseudonymisation (Article 4(5)) means processing personal data so that they can no longer be attributed to a specific data subject without additional information, provided that additional information is kept separately and protected by technical and organisational measures. Pseudonymised data are still personal data. Profiling (Article 4(4)) means any automated processing that uses personal data to evaluate personal aspects of a person, in particular to analyse or predict performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements.
5 · The actors, and why the labels decide who carries the duty
Section titled “5 · The actors, and why the labels decide who carries the duty”The deck presents this as a map of roles around a single set of personal data, all of them defined in Article 4.
- The identified or identifiable natural person the data are about
- Deck examples: an applicant, a customer
- Only a natural person, so a company is never a data subject
- Holds the rights in Articles 15 to 21
- The natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing
- Deck example: the managing director or the board, that is the organisation acting through its leadership
- Where Union or member state law determines the purposes and means, that law may name the controller
- Carries the accountability duty and the primary liability
- A natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller
- Deck examples: a recruiter, a web agency
- Decides nothing about purpose; executes instructions
- Liable under Art. 82 only for processor-specific duties or for acting outside the controller’s lawful instructions
- A recipient is anyone to whom personal data are disclosed, whether a third party or not; public authorities receiving data in a particular inquiry under law are not counted as recipients
- A third party is anyone other than the data subject, controller, processor and the people authorised to process under the direct authority of either
- Deck examples: the tax office, a freight forwarder
The fifth actor on the slide sits outside the box: the supervisory authority, defined in Article 4(21) as an independent public authority established by a member state under Article 51. In Germany the deck names the data protection authorities of the federal states.
The controller and processor distinction is the one to internalise, because it allocates duties rather than merely describing a relationship. The question is never who physically touches the data, it is who decided why and how. A cloud provider that stores your customer database has all the data and none of the decisions, so it is a processor. A payroll bureau that decides for itself to reuse employee data for its own analytics has started determining purposes, and to that extent it has become a controller in its own right and carries a controller’s duties. This is also why the label cannot simply be assigned by contract: the contract records the arrangement, but the facts about who decides determine the label.
6 · The principles: Article 5
Section titled “6 · The principles: Article 5”Every processing operation, no matter how small or how well justified, has to satisfy all of these at once. The deck lists them on the same slide as legitimacy, and Article 5 gives them their names.
| Principle | Article 5 wording, paraphrased | What it demands in practice |
|---|---|---|
| Lawfulness, fairness and transparency | Data are processed lawfully, fairly and in a transparent manner in relation to the data subject | You need a basis from Article 6, the processing must not be a trick played on the person, and they must be told what is happening |
| Purpose limitation | Collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes | Write the purpose down before you collect. Reusing the data for something new needs a compatibility assessment or a fresh basis |
| Data minimisation | Adequate, relevant and limited to what is necessary in relation to the purposes | Every field on the form has to earn its place. Collecting a date of birth because it might be handy later fails this test |
| Accuracy | Accurate and, where necessary, kept up to date, with every reasonable step taken to erase or rectify inaccurate data without delay | Correction has to be an actual workflow in the system, not a favour someone does manually |
| Storage limitation | Kept in a form permitting identification for no longer than is necessary for the purposes | Set a retention period per data category and enforce deletion. This is the principle behind the deletion stage of the life cycle in section 9 |
| Integrity and confidentiality | Processed in a way that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures | The deck summarises this as state-of-the-art security. It is the bridge from data protection law into IT security |
| Accountability | Article 5(2): the controller is responsible for, and must be able to demonstrate compliance with, all of the above | It is not enough to comply. You must hold the evidence that you comply, which is why documentation is its own topic later in the session |
Purpose limitation carries more weight than its plain wording suggests, because Article 6(4) tells you how to test whether a new purpose is compatible with the original one. The factors are the link between the old and new purposes, the context of collection and in particular the relationship between data subject and controller, the nature of the data and especially whether special categories under Article 9 or criminal conviction data under Article 10 are involved, the possible consequences for the data subject, and the existence of appropriate safeguards such as encryption or pseudonymisation.
Two further exceptions run through several principles: further processing for archiving in the public interest, scientific or historical research, or statistical purposes is not treated as incompatible under purpose limitation, and the same categories permit longer storage under storage limitation, in both cases subject to the safeguards in Article 89(1).
7 · Legitimacy: the lawful bases
Section titled “7 · Legitimacy: the lawful bases”The deck labels this legitimacy, the justification of data processing, which is a good name for it, because the underlying logic is that processing is prohibited unless justified. Article 6(1) says processing is lawful only if and to the extent that at least one of six grounds applies. The deck’s own list of justifications maps onto them directly.
| Basis | Article 6(1) | When it is available |
|---|---|---|
| Consent | (a) | The data subject has consented to processing for one or more specific purposes. Conditions in Article 7 apply |
| Contract | (b) | Processing is necessary to perform a contract to which the data subject is a party, or to take steps at the data subject’s request before entering into one |
| Legal obligation | (c) | Processing is necessary to comply with a legal obligation to which the controller is subject |
| Vital interests | (d) | Processing is necessary to protect the vital interests of the data subject or of another natural person |
| Public interest | (e) | Processing is necessary for a task carried out in the public interest or in the exercise of official authority vested in the controller |
| Legitimate interests | (f) | Processing is necessary for the legitimate interests of the controller or a third party, except where those interests are overridden by the interests or fundamental rights and freedoms of the data subject, in particular where the data subject is a child. The deck’s example of such an interest is market research |
Three details that get tested. First, the word necessary appears in five of the six bases. If the purpose can be achieved without the data, the basis fails, whatever the business rationale. Second, legitimate interests under point (f) is expressly not available to public authorities in the performance of their tasks, per the final subparagraph of Article 6(1). Third, points (c) and (e) must be grounded in Union law or member state law under Article 6(3), so you cannot simply assert a legal obligation without naming the provision that creates it.
Consent, and its conditions in Article 7. Consent is defined in Article 4(11) as any freely given, specific, informed and unambiguous indication of the data subject’s wishes, given by a statement or by a clear affirmative action, signifying agreement to the processing. Article 7 then adds four operational conditions:
Article 8 adds a rule for children. Where consent under Article 6(1)(a) is used for information society services offered directly to a child, processing is lawful where the child is at least 16 years old; below that, consent must be given or authorised by the holder of parental responsibility, and the controller must make reasonable efforts to verify this using available technology. Member states may set a lower age, but not below 13 years.
8 · Special categories: Article 9
Section titled “8 · Special categories: Article 9”Some data are treated differently because the harm from misuse is qualitatively worse. Article 9(1) prohibits processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health, and data concerning a person’s sex life or sexual orientation.
The structure is important. Article 9(1) is a prohibition, not a stricter standard. Processing only becomes possible if one of the exceptions in Article 9(2) applies, and satisfying Article 9(2) does not remove the need for a basis under Article 6. You need both.
The Article 9(2) exceptions in short: explicit consent, unless Union or member state law says the prohibition cannot be lifted that way; obligations and rights in employment, social security and social protection law where authorised by law or a collective agreement with appropriate safeguards; protection of vital interests where the person is physically or legally incapable of consenting; legitimate activities of a not-for-profit body with a political, philosophical, religious or trade union aim, limited to members and regular contacts and with no disclosure outside without consent; data manifestly made public by the data subject; establishment, exercise or defence of legal claims, or courts acting judicially; reasons of substantial public interest on the basis of proportionate law; preventive or occupational medicine, assessment of working capacity, medical diagnosis, provision of health or social care or treatment, or management of health systems, subject to the professional secrecy condition in Article 9(3); public interest in the area of public health; and archiving in the public interest, scientific or historical research or statistical purposes under Article 89(1). Article 9(4) lets member states add further conditions or limitations for genetic data, biometric data and health data, which is what German law does through FDPA § 22.
Article 10 sits next to this and handles personal data relating to criminal convictions and offences: such processing based on Article 6(1) may only be carried out under the control of official authority or where authorised by Union or member state law with appropriate safeguards, and any comprehensive register of criminal convictions may be kept only under the control of official authority. Note that Article 4 defines three of the special categories precisely: genetic data (4(13)), biometric data (4(14)) and data concerning health (4(15)).
9 · The data subject and the rights they hold
Section titled “9 · The data subject and the rights they hold”The deck groups these as Articles 12 to 14 for information and Articles 15 to 21 for rights. The split is between what you must tell people without being asked, and what they can demand from you.
| Article | The right or duty | Plain reading |
|---|---|---|
| Art. 12 | Transparent information, communication and modalities for exercising rights | Information under Articles 13 and 14 has to be given in a usable form, and requests have to be handled through a workable process |
| Art. 13 | Information where data are collected from the data subject | The privacy notice at the point of collection |
| Art. 14 | Information where data have not been obtained from the data subject | You bought or received the data, so the person still has to be told |
| Art. 15 | Right of access | Confirmation of whether their data are being processed, access to the data, and the accompanying information starting with the purposes of the processing |
| Art. 16 | Right to rectification | Correction of inaccurate data without undue delay, and completion of incomplete data including by a supplementary statement |
| Art. 17 | Right to erasure, the right to be forgotten | Erasure without undue delay in the listed situations, with a matching obligation on the controller |
| Art. 18 | Right to restriction of processing | Freeze rather than delete, for example while a contested accuracy claim is being verified |
| Art. 19 | Notification obligation | Rectification, erasure or restriction must be passed on to each recipient the data were disclosed to, unless impossible or disproportionate, and the data subject can ask who those recipients are |
| Art. 20 | Right to data portability | Receive the data they provided in a structured, commonly used and machine-readable format, and transmit it to another controller without hindrance |
| Art. 21 | Right to object | Object on grounds relating to their particular situation to processing based on Article 6(1)(e) or (f), including profiling on those bases. Processing must stop unless the controller demonstrates compelling legitimate grounds overriding the person’s interests, or grounds for legal claims. For direct marketing the right to object is separate |
Article 19 is the one people forget, and it is the one that turns a single deletion request into an engineering problem: if you have shared the record onward, you have to chase it. Note also the interaction between sections 7 and 9. Article 21 attaches specifically to the public interest and legitimate interests bases, so the basis you pick determines which rights the person can then exercise against you. Choosing a lawful basis is therefore also choosing your future obligations.
10 · The life cycle of personal data
Section titled “10 · The life cycle of personal data”The deck closes the introduction with a simple picture that ties the principles to an operational reality: personal data have a birth, a life and a death, and each stage has its own duties.
11 · The data protection officer
Section titled “11 · The data protection officer”The deck’s session plan puts the question of who is liable inside the company on the agenda, and the GDPR’s answer to part of it is a named role. Article 37(1) requires the controller and the processor to designate a data protection officer in three cases: where the processing is carried out by a public authority or body, except courts acting judicially; where the core activities consist of processing operations that by their nature, scope or purposes require regular and systematic monitoring of data subjects on a large scale; and where the core activities consist of processing on a large scale of special categories under Article 9 or criminal conviction data under Article 10.
Outside those three cases, appointment is voluntary unless Union or member state law requires it, per Article 37(4). A group of undertakings may appoint a single officer provided that officer is easily accessible from each establishment. The officer must be designated on the basis of professional qualities, in particular expert knowledge of data protection law and practice, may be either a staff member or an external service provider, and their contact details must be published and communicated to the supervisory authority.
Article 38 requires the controller and processor to involve the officer properly and in a timely manner in all issues relating to the protection of personal data, and to support them with the resources and access needed to do the job. Article 39(1) then lists the tasks: inform and advise the controller, processor and processing staff of their obligations; monitor compliance including the assignment of responsibilities, awareness-raising, staff training and related audits; advise on and monitor the data protection impact assessment under Article 35; cooperate with the supervisory authority; and act as the contact point for that authority, including for the prior consultation under Article 36. Article 39(2) adds that the officer must have due regard to the risk associated with processing operations, taking into account their nature, scope, context and purposes.
The management point is that the officer advises and monitors but does not become the controller. Designating someone does not transfer the accountability duty in Article 5(2) away from the organisation.
Case corner
Section titled “Case corner”Merck and the NotPetya war clause.
The facts. In 2017 Merck was the victim of a NotPetya malware attack. The malware spread to 40 000 Merck computers and caused more than 1.4 billion dollars in losses, hurting the company’s revenues.
What the insurers argued. Merck’s insurers denied coverage, citing the hostile or warlike action exclusion in the policy. The commercial logic of such a clause is that insurers do not underwrite the consequences of war, and NotPetya was widely attributed to a state actor. So the insurers’ position was that this was an act of war by another name.
What the courts held. In December 2021 the trial court determined that the exclusion precludes only a physical act of warfare rather than a malware hack, holding that a hostile or warlike action means traditional war involving, in the court’s words, hostilities between armed forces of two or more nations or states. On appeal, the New Jersey Appellate Division affirmed that decision. The deck quotes the appellate reasoning twice. First, that in considering the plain language of the exclusion, and the context and history of its application, the court concluded the insurers did not demonstrate the exclusion applied in the circumstances of the case. Second, that the plain language of the exclusion did not include a cyberattack on a non-military company, regardless of whether the attack was instigated by a private actor or by a government or sovereign power.
Why it is the opening slide. Three things a technology manager should take from it.
The first is about magnitude. A single malware event produced a loss on the scale of a large acquisition. The Allianz Risk Barometer ranking in section 1 is not an abstraction; this is what a 44 percent risk category looks like when it lands on one company.
The second is about contract wording. The dispute was not decided on whether the attack happened, who launched it, or whether Merck’s security was adequate. It was decided on how the words in a clause written for a different era should be read. That is a contract-interpretation problem, and it belongs to the same course as the data protection rules, because both are exercises in reading a text carefully against a set of facts. If you buy cyber cover, the question to ask the broker is what the exclusions say and how they have been construed, not what the headline limit is.
The third is about the limits of insurance as a control. Merck won, eventually, after years of litigation. Winning a coverage dispute is not the same as being protected: the cash was out of the door long before the appellate ruling. Insurance is a way of financing a loss that has already occurred, and it is not a substitute for the integrity and confidentiality principle in Article 5(1)(f) or for the technical and organisational measures that implement it.
Worked example
Section titled “Worked example”The process: an online job application handled through a careers portal, which is the example the deck itself uses in the actors slide and in the life cycle slide.
| Question | Answer for this process | Why |
|---|---|---|
| Who is the controller | The hiring company, acting through its management | It determines the purposes and means: it decides to recruit, defines the role, sets the selection criteria and decides how long applications are kept. Article 4(7) |
| Who is the processor | The web agency operating the careers portal, and an external recruiter sourcing candidates on instruction | They process on the company’s behalf without setting the purpose. Article 4(8). If the recruiter starts building its own candidate database for resale it becomes a controller for that activity |
| Who is the data subject | The applicant | An identified natural person, one of the deck’s two named examples |
| Who else receives data | Interviewers inside the company act under the controller’s authority. A payroll provider or the tax office only enters the picture once someone is hired | Article 4(9) and 4(10). Recipients and third parties are distinguished by whether they sit under the controller’s or processor’s direct authority |
| What personal data | Name, e-mail address, telephone number, CV content, interview notes and the hiring decision. Application forms should avoid special-category data | The first four map directly onto the identifier examples on the deck’s Article 4(1) slide |
| What is the purpose | Assessing the applicant’s suitability for the specific advertised role, and running the selection process to a decision | Must be specified, explicit and legitimate before collection. Article 5(1)(b) |
| Which lawful basis | Article 6(1)(b), processing necessary to take steps at the request of the data subject prior to entering into a contract | The applicant asked to be considered for an employment contract, so the processing is the very thing they requested. Consent would be a poor fit here, because it is withdrawable mid-process and because Article 7(4) casts doubt on consent given inside an imbalanced relationship |
| Which principles bite hardest | Data minimisation, storage limitation, transparency, accuracy | See the commentary below |
Commentary. The interesting work is in the last row. Data minimisation rules out the standard form fields that nobody can justify against this purpose: date of birth, marital status, a photograph. Storage limitation forces a decision that recruitment processes usually dodge, namely how long a rejected applicant’s file is kept and on what reasoning; the life cycle slide says to set the storage duration and erase once the purpose of use no longer applies, so keeping every CV forever in case something suitable turns up is a breach unless a separate basis and retention period are set for a talent pool. Transparency means the Article 13 information has to be delivered at the point of collection in the portal, not buried in a footer. Accuracy matters because interview notes are opinions about a person and are still personal data, reachable by the Article 15 right of access. And because the basis is Article 6(1)(b) rather than (e) or (f), the Article 21 right to object does not attach, which is a concrete illustration of how the choice of basis shapes the rights that follow. Finally, in Germany this sits in the employment context, so FDPA § 26 is the national provision to read alongside the GDPR.
Apply it to your project
Section titled “Apply it to your project”-
Write down the processing operation in one sentence, in verbs. Use the Article 4(2) vocabulary: are you collecting, storing, sharing, combining, retrieving, or erasing? If no verb from that list applies, the Regulation may not be engaged at all.
-
Check whether the data are personal data at all. Can any natural person be identified directly or indirectly from what you hold, alone or combined with something else you can reach? Remember that pseudonymised data still count. If the answer is genuinely no, stop here.
-
Confirm the GDPR reaches you. Run Article 2 for material scope and Article 3 for territorial scope. The usual trigger for a technology product is Article 3(2): European users being offered goods or services, or having their behaviour monitored.
-
Name the controller and every processor, in writing. Ask who decides the purposes and means, not who touches the data. Where a vendor is involved, decide honestly whether they are executing your instructions or making their own decisions, because that determines who carries the duty and who bears the liability under Article 82.
-
State the purpose before you state the data. Specified, explicit and legitimate. If the purpose can only be written vaguely, that is a sign the processing has not been thought through, and purpose limitation will fail later when someone reuses the data.
-
Pick exactly one lawful basis from Article 6(1) and write down why it fits. Test the word necessary against your own purpose. Do not default to consent because it feels safest; if you do use consent, check it against all four conditions in Article 7 and remember it can be withdrawn at any time.
-
Screen for special categories. Does anything in the data reveal racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, or is it genetic data, identifying biometric data, health data or data on sex life or sexual orientation? If so, Article 9(1) prohibits the processing until you have an Article 9(2) exception in addition to the Article 6 basis, and you should also check FDPA § 22.
-
Walk each of the seven Article 5 principles against the design. For each one, name the concrete feature that implements it: the field list for minimisation, the retention job for storage limitation, the notice text for transparency, the correction workflow for accuracy, the encryption and access control for integrity and confidentiality.
-
Plan the life cycle to its end. Set the storage duration at collection time and build the deletion. Then check that the data subject rights in Articles 15 to 21 are technically deliverable, including the Article 19 duty to pass rectification, erasure and restriction on to every recipient you disclosed to.
-
Decide whether a data protection officer is required, by testing your core activities against Article 37(1): public authority, large-scale regular and systematic monitoring, or large-scale special-category or criminal-conviction data. If one is appointed, involve them early under Article 38 rather than presenting them with a finished design.
Key terms
Section titled “Key terms”| Term | What it means in plain words |
|---|---|
| Personal data | Any information about a natural person who is identified, or who could be picked out directly or indirectly using an identifier such as a name, customer number, telephone number, online identifier or location data |
| Data subject | The living natural person the data are about, for example an applicant or a customer. Never a company |
| Processing | Practically anything you do with personal data, automated or not: collecting, storing, sharing, consulting, combining, restricting, erasing, destroying |
| Filing system | Any structured set of personal data accessible by specific criteria, which is what brings non-automated paper records inside the Regulation |
| Controller | Whoever determines the purposes and means of the processing, alone or jointly. The one who decides, and therefore the one accountable |
| Processor | Whoever processes personal data on the controller’s behalf, following instructions and setting no purposes of their own |
| Recipient | Anyone the data are disclosed to, whether a third party or not |
| Third party | Anyone other than the data subject, the controller, the processor and the staff authorised under their direct authority |
| Supervisory authority | The independent public authority set up by a member state to enforce the rules, in Germany the data protection authorities of the federal states |
| Pseudonymisation | Splitting off the key that links data to a person and protecting it separately. Reduces risk, but the data remain personal data |
| Profiling | Automated processing that evaluates or predicts personal aspects such as work performance, economic situation, health, preferences, reliability, behaviour or location |
| Legitimacy | The justification of processing: at least one of the six Article 6(1) grounds must apply, otherwise the processing is unlawful |
| Consent | A freely given, specific, informed and unambiguous indication of wishes by statement or clear affirmative action, demonstrable by the controller and withdrawable at any time |
| Purpose limitation | Purposes must be fixed before collection, and reuse for a new purpose needs a compatibility check or a new basis |
| Data minimisation | Only data that are adequate, relevant and limited to what the purpose actually requires |
| Storage limitation | Keep identifiable data no longer than the purpose needs, which means setting a retention period and deleting |
| Accountability | The controller must not only comply but be able to demonstrate compliance, which is why documentation exists |
| Special categories | The Article 9 list whose processing is prohibited unless an Article 9(2) exception applies on top of an Article 6 basis |
| Data protection officer | The internal or external expert who advises, monitors compliance, advises on impact assessments and is the contact point for the supervisory authority |
Test yourself
Section titled “Test yourself”- Summarise the Merck NotPetya dispute in four sentences: what happened, what the insurers argued, what both courts decided, and on what reasoning.
- Give the Article 4(1) definition of personal data in your own words, and explain why a customer number counts while a company’s registration number does not.
- A vendor hosts your customer database and does exactly what your contract tells it to do. Is it a controller or a processor, and why does the answer matter for liability?
- List the seven principles in Article 5 and give one concrete design decision that each one forces.
- Name the six lawful bases in Article 6(1). Why is consent usually the weakest choice for a business process, and which two conditions in Article 7 explain that?
- What does Article 9 do differently from Article 6, and what two things must you have before you may process health data?
Revision summary
Section titled “Revision summary”Next: Breaches, Documentation & IT Security → - what you must do when something goes wrong.