The previous lesson closed the regulatory map by pointing to the one rule that reaches Nimbus always, with no size thresholds and without depending on any customer. And with a particularity that multiplies its demands: the appointment history of a physiotherapy clinic reveals information about a person's health, even though the database holds nothing more than a name, a phone number and a date. This lesson goes down into the practical detail: who answers for what, which principles bind, how a data-subject right is actually handled — including the uncomfortable question of how you erase someone who sits inside a backup — which documents have to exist in writing, and what happens exactly during the 72 hours after a breach is discovered.

⚠️ Validation note — read it before going on

This lesson is training material and does not constitute legal advice. The templates, criteria and examples it contains are didactic and are built around a fictitious company. Real-world application of the GDPR depends on the specific processing operations, the sector, the contracts and the supervisory authority's interpretation, and rules and their guidance get updated. Before taking any decision: verify the version in force of Regulation (EU) 2016/679, of Organic Law 3/2018 (LOPDGDD, the Spanish Data Protection Act) and of the guidance of the AEPD (the Spanish Data Protection Agency), and validate it with a professional — a lawyer specialising in data protection, a Data Protection Officer (DPO) or your compliance lead. A mistake in this field is not fixed with a patch.

1. Why this lesson matters especially to Nimbus
2. Concepts, precisely: personal, pseudonymised, anonymous
3. Controller and processor: Nimbus is both
4. The article 5 principles, applied
5. Lawful bases: article 6 and article 9 for health data
6. People's rights and how they are actually handled
7. Documentary obligations: the RoPA and the Impact Assessment
8. Privacy by design and by default
9. Article 32 and why module 5 is its answer
10. Processors, sub-processors and the article 28 contract
11. International transfers
12. Breach notification and the 02-06 incident under the GDPR
13. The DPO, the penalty regime and the relationship with the clinics

Database A-01 contains no diagnoses, no medical reports and no prescriptions. It contains names, e-mail addresses, phone numbers and an appointments table with a date, a time and a site. A reasonable developer would say that is contact data and a diary. And yet: if the site is a physiotherapy clinic, knowing that a particular person has attended every Tuesday for the past four months reveals information about their health. No diagnosis is needed. Data concerning health is not only data describing a condition, but anything that allows information about the state of health of an identified or identifiable person to be inferred. And health data is a special category under article 9, whose processing is prohibited as a general rule unless one of the exhaustive exceptions in paragraph 2 applies.

This has three consequences that run through the whole lesson and explain why Nimbus cannot treat this matter like any other SME: the lawful basis is more demanding, because article 6 is not enough and an exception under 9.2 is also needed; the Impact Assessment is probably mandatory, because there is large-scale processing of special categories (section 7); and the risk threshold for notifying a breach to the individuals concerned drops sharply, because the risk to rights and freedoms from a leak of health data is high almost by definition (section 12).

And one architectural nuance worth fixing right away: the same field has a different nature depending on the customer. An appointment at a gym is an appointment; the same row, with the tenant_id of a clinic, reveals health. Applying two levels of protection depending on the tenant complicates life enormously, so the right decision is to treat the entire appointment history at special-category level — which was already decided technically in 03-07 with field-level encryption of the clinical notes.

These four definitions decide whether the GDPR applies to a data set or not, and they are constantly confused.

The point that causes the most mistakes, already flagged in 03-07: pseudonymisation does not take data out of the GDPR. It is an excellent security measure — article 32.1.a cites it expressly — and it reduces the impact of a breach, but as long as the key that reverses it exists somewhere, there is still personal data and all rights and obligations still apply. Many projects are designed on the opposite belief and discover too late that their "anonymised analytics database" is a personal database with no lawful basis. Real anonymisation, by contrast, is hard: you have to remove not only the direct identifiers but the possibility of reidentification by combination. If Nimbus publishes a dashboard with "patients by time slot, site and postcode", a slot with two people in a small postcode identifies somebody; and the techniques that prevent that — aggregation with a minimum threshold, generalisation, noise — destroy part of the data's usefulness. Hence the practical rule for Iván's team: when in doubt, it is personal data. The cost of treating something as personal when it was not is documentation; the cost of the opposite mistake is an infringement.

This distinction determines who answers for what, and it is the most frequent conceptual error in a SaaS. The controller is the one who decides the purposes and the means — what the data is processed for and how, in essence; the processor is the one who processes it on behalf of the controller, following its documented instructions.

Nimbus wears two hats at once, and confusing them is expensive:

The most important practical consequence, and the one to commit to memory: if Nimbus used the clinics' appointment history to improve its product, train a predictive model or produce market reports, it would stop being a processor and become the controller of that processing — with no lawful basis, with no information given to the patients and with special category data. It is one of the most serious infringements a SaaS can commit, and it happens many times without bad faith, simply because somebody in product thinks it is a good idea; that is why it should be written into POL-05 and into the development training in 06-05. And a clarification that often surprises people: the processor is not exempt from liability. Article 82 allows a data subject to claim directly against the processor when it breaches obligations that the Regulation imposes specifically on it or acts outside the controller's instructions. Being a processor is not a shield.

The six principles plus the seventh that governs them, translated into concrete Nimbus decisions:

Minimisation: is a DNI needed to book a physiotherapy session? The thought exercise has to be done field by field, and there is almost always something surplus:

The design conclusion is counter-intuitive for many product people: the safest field is the one that does not exist. A DNI that is never collected cannot leak, does not need encrypting, does not appear in a breach and does not have to be deleted. Every field removed from the form simultaneously reduces the risk, the compliance work and the impact of an incident.

Nimbus's retention policy (a didactic example; real periods must be set with legal advice and, in the case of patient data, they are decided by the clinic as controller, not by Nimbus):

Two disciplines separate a real retention policy from a decorative one: the periods execute themselves — a cron or a lifecycle policy, not a reminder for Lucía — and every period has a written justification. "Just in case" is not one; keeping data indefinitely breaches article 5.1.e and is what turns a small breach into a big one.

Every operation needs at least one lawful basis from article 6, and you cannot stack them for convenience: you choose one, document it and communicate it.

Why consent is almost never the best basis, even though it is the one everybody names first: it is withdrawable at any time and as easily as it was given, which leaves the controller in an impossible position if the processing was indispensable; it must be freely given, and if the service cannot be used without consenting, it generally is not — making a booking conditional on marketing consent is the classic vice; and you must be able to demonstrate that it was obtained: who, when, with what exact wording and which version. For the core of the service the correct basis is usually performance of the contract (6.1.b) for appointments and legitimate interests (6.1.f) for the security logs, with the balancing test written down. Consent is left for what really is optional: marketing communications, analytics cookies, ancillary features.

Article 9 and health data. Processing special categories is prohibited, save for an exception under 9.2. The relevant ones here: (a) explicit consent — a frequent route in the private sector, and "explicit" requires a clear, specific statement, not a generic tick-box; (h) preventive medicine, diagnosis or the provision of health care, the natural route for a healthcare provider and subject to the professional secrecy obligation of 9.3; (f) legal claims; and (i) public health, which belongs to authorities.

An important note: the article 9 exception does not replace the article 6 basis, it is added to it; both are needed. And the one who determines them for patient data is the clinic as controller, not Nimbus. What Nimbus must do is two things: not impose a design that forces the clinic into an inappropriate basis — for example, a mandatory clinical-reason field — and document in the contract that it will not use that data for its own purposes.

Validation note. Choosing the lawful basis and the article 9 exception is a legal decision with penalty consequences. This table is indicative: check it with a DPO or a lawyer.

The deadline is one month from receipt, extendable by a further two months for complexity or the number of requests, informing of the extension and its reasons within the first month; the response is free of charge save for manifestly unfounded or excessive requests. And these are the three real operational problems, where organisations fail:

(a) Verifying identity without asking for too much. If somebody writes asking for all of another person's data, handling it without verification is a breach; but asking for a copy of the DNI as a matter of routine is collecting new and excessive data. The criterion is to use means you already have: if the person writes from the e-mail address associated with their account and confirms with a code sent to that address or to the registered phone number, identity is reasonably established. Only where there is a well-founded doubt do you ask for additional information, and proportionate information at that.

(b) Who the request is addressed to. A clinic patient who writes to Nimbus is addressing the processor, not the controller, and Nimbus cannot resolve it on its own: it must forward it to the clinic without delay and assist it (art. 28.3.e). Answering directly would be acting outside instructions.

(c) Erasure when there are backups, the technical problem almost nobody explains well. If a patient requests erasure and Nimbus has daily backups with 35 days of retention and Object Lock in COMPLIANCE mode (05-07), the data will still exist inside those backups and cannot be deleted from them — that immutability is precisely what protects against ransomware. The solution accepted in practice, provided it is documented: (1) effective, immediate erasure in the live systems — database, buckets, indexes, caches and third parties that received the data; (2) the backups are declared "frozen": they are not deleted, but they are not used to reintroduce the data; (3) the request is recorded in a pending-erasure list that survives a restore; (4) the restore procedure includes reapplying those erasures before service is returned, written into the runbook from 04-06, because what is not written down will not be done in the middle of a crisis; (5) the backups expire on their own after 35 days and at that point erasure is total; and (6) the data subject is informed of that residual period.

Data-subject rights procedure template:

This is the document the AEPD asks for first in any action, and not having it is in itself an infringement. Although article 30.5 provides an exemption for organisations with fewer than 250 employees, it falls away when the processing is not occasional or includes special categories — both true here — so Nimbus is obliged to keep one, in its dual capacity as controller (art. 30.1) and processor (art. 30.2).

Two warnings: the RoPA is a living document — it is updated whenever a processing operation, a sub-processor or a retention period changes, and its review date is the first thing anyone looks at — and it is not a literary exercise: if it says the notes are encrypted at field level, an inspector may ask you to prove it.

It is mandatory when the processing is likely to result in a high risk to rights and freedoms, and article 35.3 presumes that risk in three cases: systematic evaluation based on automated processing with significant effects, large-scale processing of special categories and large-scale systematic monitoring of publicly accessible areas. To those you add the list of types of processing requiring a DPIA published by the AEPD — consult it in its current version.

Does Nimbus need one? Almost certainly yes, and the one who must carry it out is each clinic as controller, with the assistance from Nimbus that article 28.3.f requires. The reasoning: there is processing of data revealing health, at a relevant scale (dozens of sites, thousands of patients), remotely and with sub-processors, one of them outside the EEA. It meets several criteria at once, and when two or more are present the practical answer is to do it. Nimbus has a very clear interest of its own in doing its own product DPIA, even as a processor: it becomes a commercial deliverable that its customers reuse, it saves each clinic from starting from scratch and it answers half a dozen questionnaires in advance. Minimum content (art. 35.7), translated:

The most common error in a DPIA deserves underlining: copying the security risk analysis. They are different analyses. In 04-01 impact was measured in euros for Nimbus; in a DPIA it is measured in harm to people — employment discrimination if it becomes known that someone attends rehabilitation, reputational damage, distress, loss of control over intimate data. The same incident has two different impacts and both must be assessed. And if, after the measures, the residual risk remains high, the prior consultation with the AEPD under article 36 applies.

Article 25 requires measures by design — when determining the means and during the processing — and by default — that only the data necessary for each purpose is processed, without the user having to intervene. Translated into Nimbus product decisions:

The last row is the most important and the cheapest: turning "is this item of data necessary?" into an item on the pull request template from 06-01. It is privacy by design implemented as a habit, and it costs one line of text.

Article 32 requires "appropriate technical and organisational measures to ensure a level of security appropriate to the risk", and it expressly mentions four: pseudonymisation and encryption; ongoing confidentiality, integrity, availability and resilience; the ability to restore availability quickly after an incident; and a process for regularly testing, assessing and evaluating effectiveness. It does not impose particular technologies: it requires you to decide on the basis of risk and be able to justify the decision, and all the technical work in the course is exactly that justification:

Article 32.1.d deserves special attention because it is the one almost nobody complies with: implementing is not enough, you have to verify effectiveness regularly. It is the thesis of 06-01 — an untested control is "planned" — and the entire subject of 06-04. A controller who tells the AEPD "we have backups" and cannot show a dated restore report does not comply with 32.1.c or 32.1.d, even if the backups exist.

Article 28 requires the relationship with a processor to be governed by a contract or other legal act with an exhaustively defined minimum content: it is the document that determines what Nimbus may do with the clinics' data, and the one they will demand at every renewal. Mandatory content (art. 28.3), with its practical drafting:

The sub-processor chain is where the problems pile up. Nimbus sub-contracts three suppliers that touch data — cloud (A-05), transactional e-mail (A-11) and the systems consultancy (A-19) — and the rules of articles 28.2 and 28.4 are three. First: the controller's authorisation is needed, specific or general in writing, and if it is general you must inform of any addition or change and allow objection — the healthy practice is a public sub-processor list with 30 days' notice. Second: the sub-processor is placed under the same obligations that Nimbus took on towards the clinic; you cannot promise the customer more than you require of the supplier. And third, the one that changes the 04-04 conversation: Nimbus remains fully liable to the clinic for the sub-processor's compliance. Outsourcing execution does not outsource liability, and the 02-06 incident is the perfect example: Nimbus answered to its customers for a failure that occurred on somebody else's premises.

Validation note. Article 28 contracts, their annexes and their audit and liability clauses have direct legal and financial effects. They are not drafted from an internet template: they are validated with legal counsel, and it is worth reviewing the standard contractual clauses the European Commission has published for controller-processor relationships.

Chapter V governs transfers outside the European Economic Area, and the important thing for an SME is that they happen constantly without anyone noticing: all it takes is a SaaS supplier hosting data abroad, or its support staff accessing from a third country. Remote access from outside the EEA is a transfer, even if the servers are in Frankfurt. That nuance is always forgotten.

When SCCs are used you must also carry out a transfer impact assessment (TIA): analyse whether the destination country's law allows access by public authorities that would hollow out the safeguards, and add supplementary measures if necessary — encryption with keys retained in the EEA, pseudonymisation, minimising what is transferred. Nimbus's specific case. The transactional e-mail provider (A-11) receives a name, an e-mail address and the reminder text, and three minimisation measures reduce the problem until it becomes manageable. Never send the reason for the appointment: the minimal text from section 8 is not just good practice, it reduces the category of data transferred and takes health out of the transfer. Do not send the site's name when it reveals a medical speciality: "You have an appointment on Tuesday at 17:00" with an authenticated link transfers far less than "Appointment at the Neurological Rehabilitation Clinic". And assess a provider hosted in the EU, where the cost is often similar and the transfer disappears altogether: the best way to manage an international transfer is usually not to make one.

A personal data breach is any breach of security leading to the accidental or unlawful destruction, loss or alteration of personal data, or unauthorised disclosure of, or access to, it. Note carefully: no attacker is required. An e-mail with a patient list sent to the wrong recipient is a breach; a lost unencrypted laptop is a breach; a tenant isolation failure that lets one customer see another's data is a breach.

Minimum content (art. 33.3): the nature of the breach, the categories and approximate number of data subjects and of records; the DPO's contact details; the likely consequences; and the measures taken or proposed, including mitigation. If not everything is available, it may be provided in phases — a key possibility, because the clock does not stop while you investigate. And the internal breach register under article 33.5 is ALWAYS mandatory, whether you notify or not: even a breach you decide not to notify is documented with the facts, the effects, the corrective measures and the reasoning for why notification was not required. It is the first thing the AEPD asks for when it arrives by another route, and its absence aggravates any case file.

To recap: entry through the consultancy's remote access (A-19), theft of a .env, exfiltration of 1.2 TB, deletion of backups, 20 days of dwell time and discovery on day 20 at 09:00.

The five legal lessons of the case:

1. The clock starts with "awareness", not with certainty. Nimbus became aware on day 20 at 09:00, when it knew with reasonable certainty that a breach had occurred. Waiting until you know everything is the mistake that multiplies fines. You can notify in phases; you cannot start late.
2. Phased notification exists precisely for this. On day 22 the scope was still undetermined. The right response is not silence: it is to notify what you know, say the investigation continues and supplement later.
3. Nimbus, as processor, does not notify the AEPD: it notifies each clinic. They are the ones who, as controllers, notify. With a brutal operational consequence: Nimbus's delay eats into the deadline of its 40 customers. That is why the contract must set a short internal deadline — 24 hours is the usual agreement — and why Nimbus must deliver usable information, not a vague e-mail.
4. Encryption as an article 34 exception does not save you here. The exception requires the data to be unintelligible to the attacker. If the attacker stole a .env with the application's credentials and exfiltrated through the application itself, the data reached them decrypted. Encrypting at rest protects against theft of the disk or the bucket, not against an attacker who has the keys. This distinction decides whether thousands of people have to be contacted or not, and it is decided at design time, months earlier.
5. The 20 days of dwell time aggravate the assessment. Article 83.2 weighs, among other criteria, the nature and gravity, whether it was intentional or negligent, the measures taken to mitigate the damage, the degree of responsibility having regard to the technical and organisational measures implemented (arts. 25 and 32) and the degree of cooperation. Twenty days undetected, with seven missed opportunities, point straight at the inadequacy of the article 32 measures.

Template for the communication to those affected (art. 34). It must use clear and plain language, not legal language:

Four drafting decisions worth copying: nothing is played down — "an incident with no consequences" destroys trust when more becomes known; it says explicitly what is NOT affected; it warns of the real, specific risk — targeted phishing using the appointment history itself; and it gives concrete actions instead of generic recommendations.

Does Nimbus need a Data Protection Officer? Article 37.1 makes one mandatory in three cases — public authorities; regular and systematic monitoring on a large scale as a core activity; and large-scale processing of special categories as a core activity — and the LOPDGDD (art. 34) adds a list of obliged entities. At Nimbus the honest analysis is that the core activity consists of processing, on behalf of third parties, data from which health data is derived, at a relevant scale. Even though its role is that of processor — and article 37 applies "to the controller and the processor" — the reasonable conclusion is that it probably is obliged, and in any case appointing one is defensible and cheap: an external DPO (2,000-5,000 €/year) also brings independent legal judgement. Requirements that cannot be forgotten: functional independence, absence of a conflict of interests — Marta cannot be the DPO, because she decides on the processing she would have to supervise — and publication of the DPO's contact details, notified to the AEPD.

Penalty regime (art. 83). Two tiers:

The percentages are calculated on the turnover of the corporate group, not of the subsidiary, and the AEPD also has other measures at its disposal that are sometimes more serious than the fine: limitation of, or an order to stop, the processing, which for a SaaS amounts to switching off the product. What the AEPD looks at in practice, with a realistic view for an SME: it rarely comes to a 38-person company on its own initiative. It arrives through a data subject's complaint or through a breach notification. And once inside, the first thing it asks for is a very predictable set of documents: the RoPA, the privacy policy and the information given to data subjects, the article 28 contracts, the breach register, the DPIA where applicable, and evidence of the article 32 measures. The article 83.2 weighing expressly values cooperation and the measures taken to mitigate, so the difference between a serious fine and a warning usually lies in being able to demonstrate diligence with documents dated before the incident. That is exactly what is built in 06-04.

The relationship with the clinics: who notifies whom. This is where there is most confusion, and the contract must resolve it with a table like this one:

The 24-hour contractual deadline is not negotiable downwards: if Nimbus notifies at 60 hours, it leaves each clinic 12 to investigate, assess and notify the AEPD, which is materially impossible, and all 40 would be in breach through their supplier's fault. It is the argument with which Marta defends the runbook internally: Nimbus's clock is not its own, it is its customers'.

• Believing that pseudonymising takes data out of the GDPR. It does not: it is an excellent security measure, not an escape route.
• Confusing the two hats. Using the clinics' patient data for product analytics or to train a model turns Nimbus into a controller with no lawful basis and with special categories. It is among the most serious infringements possible, and it happens without bad faith.
• Choosing consent by default. It is withdrawable, it must be freely given and you must be able to demonstrate it. For the core of the service: contract, or legitimate interests with a documented balancing test.
• Asking for a copy of the DNI to handle an access request. That is collecting new and excessive data: use the means you already have. And have the backup problem in erasure already solved — pending-erasure list, reapplication after a restore written into the runbook, expiry.
• Waiting until you know everything before notifying. The clock runs from awareness. Phased notification exists precisely for that.
• Trusting that "the data was encrypted" exempts you from communicating with those affected. Only if it was unintelligible to the attacker. If they stole the application's credentials, it was not.
• Tip: start with the RoPA. It is mandatory, it is the first thing you are asked for, and writing it reveals processing operations nobody had thought of, retention periods nobody had set and sub-processors nobody had authorised. And do the product DPIA even though you are a processor. It becomes a commercial deliverable your customers reuse and it answers half a dozen questionnaires in advance. And minimise in the form before you minimise in the architecture: every field you remove simultaneously reduces the risk, the compliance work and the impact of a breach. It is the cheapest measure there is.

Exercise 1 — The new smart reminders module

Product proposes a feature: analysing the appointment history of all tenants to predict which patients are going to miss their appointment and send them an extra reminder, improving occupancy at the sites. Iván has already trained the model on production data from the 40 clinics. Analyse the proposal: Nimbus's role, lawful basis, article 9, the article 5 principles compromised, article 22 and what Marta must do. State whether there is any legitimate way of offering it and on what conditions.

Exercise 2 — A small breach

Rubén, in support, replies to a clinic's query and mistakenly attaches an Excel list containing 312 patients of a different clinic — name, phone number and the dates of their appointments. He spots it himself 40 minutes later and raises the alarm. The recipient is the administrator at a customer site, who confirms by phone that she deleted the e-mail without opening the attachment. Decide, reasoning each step: is it a breach? Who is the controller and who is the processor? Does the AEPD have to be notified? And the 312 patients? What is documented in any event? What corrective action is appropriate?

Exercise 3 — An erasure request with complications

This message arrives at privacidad@nimbusreservas.example: "I am a patient of Fisio Valencia Clinic. I want you to delete all my data from your system immediately. I also want to know who has consulted my appointment history over the past year. And I refuse to have my data in the United States." Draft the action plan setting out which rights are being exercised, who handles each one, deadlines, how identity is verified, and how each point is resolved technically — including the backup problem and the e-mail provider problem.

Exercise 1

The verdict: as framed, the feature is unlawful, and an infringement has already been committed by training the model on production data. Role and lawful basis. Nimbus decides on its own the purpose (improving occupancy, improving its product) and the means (the model), which makes it the controller of this processing and not a processor — article 28.10 says so expressly. And as controller it has no lawful basis whatsoever: there is no contract with the patients, there is no consent, and legitimate interests cannot override the rights of people whose data reveals health in processing they do not expect at all. Processing the data for a purpose of its own is also acting outside the documented instructions (art. 28.3.a) and a breach of contract towards the 40 clinics.

Articles 9, 5 and 22. This is data revealing health and an exception under 9.2 would be needed: none fits, because there is no explicit consent and the healthcare exception (9.2.h) covers the provision of care, not the commercial optimisation of a software supplier's diary. Of article 5, the ones infringed are purpose limitation, flagrantly — predicting no-shows is incompatible with managing bookings — plus lawfulness and transparency and minimisation. Article 22 is not triggered if only an extra reminder is sent, but it would apply squarely if the model led to penalties, advance payment or loss of priority. And there is an infringement already committed: the trained model is the fruit of unlawful processing and models can memorise training data, so not deploying it is not enough: it must be destroyed and the destruction documented.

What Marta must do, in this order: (1) stop the initiative today; (2) find out what data was copied to which environment and delete it along with the model; (3) assess with legal counsel and the DPO whether the training constitutes a breach or a non-compliance notifiable to customers — probably yes as a breach of contract; (4) document the decision in minutes; (5) add to the product process a mandatory privacy-by-design check, because the underlying failure is not Iván's: it is that the proposal reached implementation without anyone asking the question.

A legitimate route, which exists and is workable: turn it into a per-tenant feature, where each clinic is the controller deciding to switch it on over its own data. Conditions: a model trained and run per tenant with no data mixing; the clinic updates the information it gives its patients and determines its lawful basis; it is documented as an instruction in the article 28 annex; a simple means of objecting is offered; the RoPA and the DPIA are updated. It is statistically less powerful and it is the only defensible form. The difference between a serious infringement and a valid feature is not in the technology, it is in who decides and over whose data.

Exercise 2

Is it a breach? Yes, without any doubt. There has been unauthorised disclosure of personal data to a third party: the fact that it is an internal error and not an attack is irrelevant, and the fact that the recipient is a trusted customer does not eliminate it either. It is a confidentiality breach involving data revealing health — 312 people identified as patients of a physiotherapy centre. Roles: the data belongs to a clinic's patients, so the affected clinic is the controller and Nimbus is the processor that caused the breach. Nimbus does not notify the AEPD: it notifies the clinic within the contractual deadline (24 h) and the clinic is the one that decides and notifies.

Notify the AEPD? The decision is the clinic's, but Nimbus must give it the elements and a reasoned recommendation. In favour of notifying: special category, 312 people affected, identification as patients of a healthcare centre. In favour of considering the risk unlikely: a single, identified recipient, bound by contractual confidentiality, confirmation of deletion without opening, 40 minutes of exposure and no evidence of further dissemination. The prudent recommendation is to notify, because the article 33 threshold is not "high risk" but "unless it is unlikely to result in a risk", which is a low bar; with special categories involved, arguing unlikelihood is risky, and not notifying and having it come out later is a clear aggravating factor. But it is a legal decision for the controller, who must take it with their DPO or legal counsel: this solution is training material, not an opinion. Whatever the decision, the reasoning is documented.

And the 312 patients? Article 34 requires high risk. With a single identified recipient, contractual confidentiality, deletion confirmed without opening and 40 minutes of exposure, it is defensible that high risk is not present and that individual communication is not required — which also avoids disproportionate alarm over a contained incident. It is worth reinforcing this by obtaining written confirmation of deletion from the recipient, not just a phone call. And in every case the article 33.5 register is documented: chronology, root cause, categories and number of people affected, recipient and their confirmation, risk assessment with its reasoning, decision and who took it, and corrective measures.

Corrective actions, where the real value of the exercise lies, because the root cause is not Rubén. Technical and structural: remove the possibility of exporting to Excel and attaching by hand; reports are generated from the system, filtered by tenant, with a 120 s signed URL to the authenticated recipient — if the file does not exist outside the system, it cannot be attached to the wrong e-mail; this is the C-06 pattern. Preventive: a warning in the e-mail client for attachments containing personal data going outside the domain, and a 60-second delay allowing cancellation (the 40 minutes would have been 0). Detective: check whether the D-05 threshold would have fired on this export and adjust it. Training: an anonymised case in the 06-05 micro-lesson. And very importantly: Rubén detected and reported his own mistake within 40 minutes, which is exactly the desired behaviour, and he is thanked explicitly. Punishing him would guarantee that the next error is kept quiet, and the next one could involve 40,000 records. This is the just culture of 06-05.

Exercise 3

Three different things are being exercised, and separating them is the first thing to get right: erasure (art. 17); access (art. 15) in its aspect of information about recipients and accesses — with the nuance that article 15 gives a right to know the recipients or categories of recipients, not automatically the name of every employee who looked, and the rights of those employees have to be weighed; and a statement about international transfers, which is handled as an objection or as a request for the article 15.2 information about the chapter V safeguards.

Step 0 — Role determination, which conditions everything. She says she is a patient of Fisio Valencia Clinic, so Nimbus is the processor and cannot handle the request. It must log it the same day, forward it to the clinic within 48 hours warning that the one-month deadline runs from the original receipt, tell the requester who it has been forwarded to, and offer technical assistance (art. 28.3.e). Handling it directly would be acting outside instructions, and deleting data without the controller's instruction could destroy information the clinic is obliged to retain under healthcare rules.

Steps 1 and 2 — Identity and erasure. The clinic verifies with the means it already has — a code to the phone number or e-mail address on her record — without asking for a copy of the DNI. It then assesses the article 17.3 exceptions, and here it is very likely that some apply: a legal obligation to retain clinical documentation and the possible defence of legal claims. A realistic scenario: partial erasure. What is not covered is erased (contact details, portal account, preferences, marketing communications) and the rest is restricted — retained, not processed, accessible only on request — for the legal period, explained clearly, because a "we cannot delete it" with no reason guarantees a complaint. Technically, for what is erased, Nimbus executes on instruction: deletion in the live database, in A-02, in indexes and caches, and an erasure request to the e-mail provider; and it applies the backup procedure from section 6 — pending-erasure list, backups not used to reintroduce data, reapplication after a restore written into the runbook, and expiry after 35 days, a period she is informed of.

Step 3 — Who has consulted her history. Here Nimbus delivers value that almost no supplier can: the append-only audit table from C-07, with 12 months of retention, allows a report to be generated by patient_ref with the date, time, type of access and the user's role. The reasonable balance is to give the role and organisation — "administrative staff at the centre", "supplier support under ticket #4412" — rather than employee names; and if the report revealed unjustified accesses, that is an incident in itself and triggers 04-05. Step 4 — The objection to the United States. This is answered with transparency and facts: hosting and database in the EU; the only transfer is the transactional e-mail provider, covered by SCCs with assessment TIA-2026-02, and what is transferred is limited to a name, an e-mail address and a reminder with no appointment reason and no medical speciality of the site. And a concrete alternative is offered: switch off e-mail reminders and use SMS or an in-app notification, so that there is no transfer at all in respect of her data. That is the answer that solves the person's real problem instead of debating the legal framework.

Step 5 — Deadlines and closure: everything within one month of the original receipt, not from when Nimbus forwarded it. If the 17.3 assessment complicates matters, a two-month extension communicated and reasoned within the first month. The final response, in plain language, includes what has been erased, what is retained under restriction and why, the access report, the explanation of the transfers with its alternative, and always a mention of the right to lodge a complaint with the AEPD.

You have gone through the GDPR where it is actually lived: in product decisions, in the data model, in the support inbox and in the 72 hours after bad news. You know why this affects Nimbus especially: the appointment history of a physiotherapy clinic reveals information about health, even though there is no diagnosis anywhere in the database, and that makes it a special category under article 9 with three consequences — a more demanding lawful basis, a DPIA that is probably mandatory, and a lower threshold for communicating a breach to those affected.

You handle the concepts precisely: personal data, special category, pseudonymised data that is still personal data — the mistake that sinks many analytics projects — and anonymous data with its irreducible tension between usefulness and reidentification. And you are clear about the distinction that orders everything: Nimbus wears two hats, processor in respect of its clinics' patients and controller in respect of its employees, its website visitors and its administrator users; with the red line that using customer data for a purpose of its own turns it into a controller with no lawful basis, and with the reminder that being a processor is not a shield. You apply the article 5 principles with a field-by-field minimisation analysis — where the DNI turns out to be unnecessary and the conclusion is that the safest field is the one that does not exist — and with a real retention policy, executed automatically and with a written justification on every line. You know how to choose a lawful basis and why consent is usually the worst option for the core of the service, and that the article 9 exception is added to article 6, not a substitute for it. You know how to handle the seven rights with their one-month extendable deadline, and the three operational problems nobody explains: verifying identity without asking for the DNI, forwarding to the controller when you are the processor, and the complete solution to the problem of erasing someone who sits inside an immutable backup — live deletion, pending-erasure list, reapplication after a restore written into the runbook, and expiry after 35 days.

You have the documentary obligations sorted: a full RoPA with its two sections — controller and processor — and real entries filled in, and a DPIA with its article 35.7 content and the error that ruins it, which is copying the security risk analysis instead of measuring the harm to people. You can translate article 25 into concrete product decisions, including the cheapest of all: asking "is this item of data necessary?" in the pull request template. And you have the table that connects each article 32 requirement to the work of module 5, with the paragraph almost nobody complies with — 32.1.d, regularly verifying effectiveness — flagged as the subject of the next lesson. You have a command of the article 28 contract with its mandatory clauses, the sub-processor chain with the rule that outsourcing execution does not outsource liability, and the international transfers that happen without anyone noticing — including remote access from outside the EEA — with the most elegant solution for Nimbus's case: minimising the reminder's content until health is taken out of the transfer. And you have analysed the 02-06 incident under the GDPR with its 72-hour clock running from awareness and not from certainty, phased notification, the fact that Nimbus's delay eats into the deadline of its 40 customers, why encryption at rest did not save it from communicating with those affected when the attacker held the keys, and how the 20 days of dwell time aggravate the article 83.2 assessment. Along with the template for the communication to those affected and its four drafting decisions. You close with the DPO — probably mandatory, external, independent and free of conflicts of interest — the two penalty tiers, what the AEPD really asks for when it arrives, and the table of who notifies whom between Nimbus and the clinics.

And notice what has come up again and again in this lesson: RoPA, contracts, breach register, restore reports, evidence of the article 32 measures, documents dated before the incident. The GDPR does not reward being secure: it rewards being able to demonstrate it, and it calls that accountability. NIS2 asked for the same thing, an ISO 27001 auditor asks for the same thing and so does the customer with the 90-question questionnaire. In Compliance and Auditing (06-04) we turn that demand into a system: what makes a piece of evidence valid, how its collection is automated so that an audit stops being three days of panic, how the traceability matrix we have been carrying since 04-03 is completed, how a real auditor behaves and what they ask when they request a sample, and how you respond to a finding without arguing or exaggerating. All the technical work of module 5 left a trail; now we are going to collect it.