Guidelines›Security›GDPR · European Union

European Union · Regulation (EU) 2016/679

GDPR, article by article, and what is actually built.

GDPR is not mainly a security regulation. Security is one article out of ninety-nine. Most of it is about the rights a person has over data held about them, and about being able to show what you are doing and why. That is the part software either carries or does not, and this page goes through it article by article.

Health data gets the strictest treatment GDPR has. It is what the regulation calls special category data, which means processing it is forbidden by default and only becomes lawful when a specific condition in Article 9 applies. Getting that condition right, and recording it, is where a lot of health deployments go wrong.

The technical foundations — encryption, access control, the audit log, retention — are shared with every other country and are described on the main security page. What follows is what the European module adds on top.

Data protection officers Compliance leads Security reviewers Counsel running diligence

72 hto notify the authority Art. 9(2)(h)the basis for treatment records 3rights built as workflows 2governance records kept live 0consent theatre

Lawful basis The rights Breach notification Governance records Where the edges are What stays with you

01 — Lawful basis

Why treatment records do not rest on consent, and why that is the safer answer

The instinct in most organisations is to ask people to consent. For clinical records that instinct is wrong, and following it creates a serious problem later.

Consent under GDPR must be freely given. If a person cannot refuse without losing something they need, the consent is not valid. Someone in the middle of a course of therapy cannot meaningfully refuse to let their therapist keep notes. So consent obtained in that setting is likely to be invalid — and worse, consent can be withdrawn, which would leave the clinic with an obligation to keep records and no lawful basis for keeping them.

The correct condition for treatment records is Article 9(2)(h): processing necessary for the provision of health or social care. It is stable, it does not evaporate when somebody changes their mind, and it is what the regulation intended for exactly this situation.

Requirement	Status	What is built
Lawful basis recorded per document typeArt. 6 · Art. 9	✓	Every document type carries both its ordinary lawful basis and its special-category condition, plus a free-text note for the reasoning. The type is what says what kind of processing this is, so recording it against the type means it applies to every document filed under it, automatically and consistently.
The basis is set before the data exists	✓	Because it lives on the type rather than on the individual document, the question is answered at configuration time rather than by whoever is filing at the moment. That is the difference between a policy and a control.
Consent where consent is genuinely the basisArt. 7	✓	Marketing contact, research participation and similar do rest on consent, and the e-signature module holds those as signed, revocable consents rather than a tick box that nobody can produce later.

✓BuiltIn the software now, and demonstrable. ⚙Built — you set the valueNothing is missing; the answer is a decision for your service. ◐Partly builtSomething is genuinely missing, and the row says what. —Not builtNamed in the gaps section rather than left to be found.

02 — The rights

Access, erasure and portability, built as workflows rather than promises

Each of these rights has a deadline and a decision behind it. Built as an inbox and a good intention, they get missed. Built as a tracked record with a computed due date, they get answered — and, just as importantly, you can show afterwards that they were.

Right	Status	What is built
Right of accessArt. 15 · Art. 12(3)	✓	A tracked request with the subject, the scope, the documents it covers, a computed due date and a fulfil-or-refuse decision. The deadline is one calendar month, counted as a month rather than as 30 days — which matters, because a request landing on 31 January is not due 30 days later. The extension Article 12(3) allows is built too: it records the reason and, separately, the date the person was actually told, because an extension nobody was told about is not an extension.
Right to erasureArt. 17	✓	Carried out by destroying the encryption key rather than deleting the row — see the secure documents page for how that works and what it costs. The content becomes permanently unreadable while the empty shell and the access log survive — so the right is honoured and the evidence of what was held and who saw it is not destroyed with it. The request records the assessment behind the decision, and lists documents that were blocked from erasure and why.
Erasure is not absolute, and the system knows thatArt. 17(3) · Art. 9(3)	✓	Clinical records rarely qualify for outright erasure: retention obligations and professional secrecy usually override. Nothing is destroyed while a legal hold or a live retention period stands, and the blocked documents are listed on the request so the refusal is explained rather than implied. A right to erasure does not cancel an obligation to keep.
Right to portabilityArt. 20	✓	An export built in memory and streamed as a zip: metadata as JSON, content as filed. Every document included is logged individually, which matters — otherwise a bulk export becomes a quiet way to read a whole record without leaving a trace of each read.
Right to rectificationArt. 16 · Art. 19	✓	Handled through the shared amendment workflow: a correction is filed as a new version and the original stays intact. Complete through what happens when a correction is refused — the person's statement of disagreement in their own words, the clinic's reply, and the rule that both travel with any future disclosure. Recipients who already hold the earlier version can be notified, which is what Article 19 asks for.
The first copy is freeArt. 15(3)	✓	The Article provides the copy and permits a fee only for further copies. Enforced rather than left to whoever fills the form in: the system counts the copies this person has actually been given, and refuses a fee on the first one. A refused earlier request does not count — nothing was provided, so the next request is still the first copy. Waiving the fee satisfies it, because waived means nothing is charged.
Right to restrict processingArt. 18	✓	A restriction seals the documents it covers and records the reason and the decision. Lifting it restores the document's previous sensitivity label rather than making it ordinary.

03 — Breach notification

Two deadlines from one moment, and an exemption you have to earn

This is where the encryption design pays for itself. Article 34(3)(a) says you do not have to tell the individuals if the data was encrypted — but only if you can show the keys were not taken as well. That single condition is why the keys are held where they are, outside the database and never in the same backup as the data.

Hour zero Becoming aware

Both deadlines run from the moment you become aware, not from the moment the incident happened. The breach record makes that moment a required field, so it is established at the start rather than reconstructed under pressure later.

Within 72 hours The supervisory authority

Article 33 gives 72 hours from awareness. The system computes that deadline from the awareness time and a scheduled job warns before it runs out — twelve hours ahead — because a deadline nobody is reminded of is a deadline that gets missed on a Friday evening.

Without undue delay · unless The people affected

Article 34 requires telling the individuals as well, unless the exemption applies. The record holds the list of affected people and the documents involved, so the notification list is derived from evidence rather than estimated.

The condition Was the data encrypted, and were the keys taken?

Two separate stored questions: whether the data was encrypted, and whether the keys were compromised. An unanswered keys question resolves against the exemption. You cannot close a breach as non-notifiable by leaving the awkward field blank.

The output A decision with its reasoning attached

The record produces whether individual notification is required, an exemption note explaining the reasoning, and the dates on which the authority and the individuals were actually told. That is the document you hand a regulator.

One record, assessed once, against whichever rules apply

The breach record itself lives in the shared core, so every deployment gets it: when you became aware, what was involved, who was affected, whether the data was encrypted and whether the keys were taken. The European module adds the 72-hour Article 33 deadline and the Article 34 decision described above. The United States module adds its own layer on the same record — the four-factor assessment, the 60-day clock and the reporting thresholds. An incident that touches both is assessed once and answered twice.

04 — Governance records

The two documents that are wrong the moment you stop maintaining them

GDPR asks for two pieces of written governance. Most organisations produce both as documents before go-live and never touch them again, at which point they describe a system that no longer exists. Both are held here as live records instead, which is the only version of them that survives contact with a real deployment.

Article 30

Record of processing activities

A list of what you process, why, about whom, who receives it, whether it leaves the EU, how long you keep it and what protects it. It is the first thing a supervisory authority asks for, and it is the fastest way to look unprepared if it is stale.

Each activity records its purpose, the categories of data and of people, recipients, transfers outside the EU, retention and security measures
Ships pre-filled with the activities this platform actually performs: clinical records, subject rights handling and the audit log
Kept as records that can be edited as the deployment changes, rather than as a document that has to be rewritten

Article 35

Data protection impact assessment

Required where processing is likely to result in a high risk to people's rights. Large-scale processing of health data always meets that test, so for a clinic there is no argument to have about whether one is needed.

Records the nature and scope of the processing, why it is necessary and proportionate, the risks, the measures addressing them, the residual risk, the owner and a review date
Ships partly filled in as a starting point, because the parts that are true of the platform are the same in every deployment
The parts only your deployment knows are marked as such rather than left blank, so an unfinished assessment looks unfinished
Carries the consultation field for the case where residual risk stays high and the authority has to be consulted before you begin

05 — Where the edges still are

What is not built, said out loud

The European module is the most complete of the three, because GDPR's rights machinery is what it was written for. It is still not finished. Here is what is not there, taken from reading the code rather than from a wishlist.

Still open

Objection under Article 21 is not its own request type. In a treatment setting it is rarely the operative right — processing rests on Article 9(2)(h) rather than legitimate interests — but if someone raises it, there is no dedicated place to record the decision.
No record for automated decisions or profiling under Article 22. The platform can make recommendations. If you switch that on, this becomes part of your assessment and there is nowhere in the system that tracks it.
Transfers outside the EU are recorded as free text. The processing register has a field for them, but not a structured record of the safeguard relied on. If you use processors outside the EU, this is where an auditor will want more than a sentence.
The data protection officer is not modelled. Where you must appoint one, the appointment and the published contact route live outside the system. The equivalent US roles — security official and privacy official — do have records, so this is an asymmetry rather than a design decision.
Encrypted documents cannot be searched by content. A direct consequence of the encryption, and it will not change. Documents are found by subject, type and date.

Built, but only worth what you put in it

The impact assessment ships partly filled in. That is a head start, not a finished document. The parts marked as deployment-specific need real answers before it means anything.
The processing register has to track reality. It arrives pre-filled with what the platform does. Every processor you connect and every purpose you add is yours to record.
The scheduled jobs have to keep running. Retention, disposal and the breach deadline warning all run on a schedule. A job that stops quietly is a compliance problem that only appears in an audit.

06 — Your side of the line

What GDPR asks of your organisation, not of any software

GDPR places duties on the controller, which is your clinic. A platform can hold the evidence and make the workflows real. It cannot be the controller.

Not legal advice, and no product is GDPR certified

No authority certifies software as GDPR compliant. What this page describes is the set of technical and organisational measures the platform provides. Confirm every item with counsel qualified in the member state you operate in — national law adds to GDPR, and health is one of the areas where it adds most.

You are the controller. The purposes and means of processing are your decisions. The platform records them; it does not choose them.
Data processing agreements are yours to sign, along with any sub-processor terms for services you connect — payments, messaging, storage, or an AI provider if you enable one.
Member-state law goes further. Germany's §203 StGB on professional secrecy and §630f BGB on treatment records are examples. Retention periods in particular are set nationally and must be confirmed locally.
Appointing a data protection officer. Large-scale processing of special category data usually requires one. The appointment, and publishing the contact route, are yours.
The impact assessment must actually be completed. It ships partly filled in, which is a head start, not a finished document. The parts marked as deployment-specific need real answers.
Prior consultation with the authority. Where residual risk stays high after mitigation, Article 36 requires you to consult before starting. That is a decision, not a feature.
Watching the scheduled jobs. Retention, disposal and the breach deadline warning all run on a schedule. A job that quietly stops is a compliance problem that only appears in an audit.

The honest one-paragraph summary

The lawful basis is recorded per document type and correctly uses Article 9(2)(h) rather than consent. Erasure is real and is performed by destroying the encryption key, so the right is honoured without destroying the evidence that a record existed. Portability produces a streamed export with every document logged individually. Breach notification is built with both deadlines, the encryption question and the keys question, and an unanswered keys question counts against the exemption. The processing register and the impact assessment are live records rather than stale documents, and the access deadline is one calendar month with the Article 12(3) extension built on top of it. What is missing is objection as its own request type, a record for automated decisions, structured records for transfers outside the EU, and a place to hold the data protection officer appointment.

07 — Where to go next

The rest of the picture

SharedSecurity overviewThe technical core every country sits on: encryption, access control, audit log, hardening. JurisdictionHIPAA · United StatesThe Privacy and Security Rules, psychotherapy-notes separation and 42 CFR Part 2. JurisdictionUK GDPR · United KingdomThe serious-harm test, the NHS retention schedule and records of the deceased. The coreSecure documentsHow erasure by key destruction actually works, and the risks that come with it.